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A source receives a multicast packet on an access port from 
a source host, determines a group address in the multicast 
packet, and composes and sends a "sender present" message 
to other switches on its network ports. The receiving 
switches determine whether a local host wishes to join the 
group and if so, send a map message back toward the source 
switch on a predetermined path between the receiving 
switch and the source switch. A map message may terminate 
at a switch on the path that already has a connection for this 
group/source pair, and join into this connection as an addi- 
tional output port. In this manner, a "signal out, connect 
back" mettiod is provided for establishing a connection path 
firom the sender to multiple receivers. In addition, muhicast 
traffic can be sent across a switch/router interface in either 
direction, providing for controlled miUticast traffic between 
router-based networks and switch-based networks. 
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MULTICAST SWITCHING 

HELD OF THE INVENTION 

The present invention relates to a method and apparatus 
for controlling the flow of multicast traffic on a communi- 
cations network, and more particularly to a method and 
apparatus for establishing a connection path for muhicast 
trafl&c through a switched network, and across router/switch 
boimdaries, which conserves network bandwidth. 

BACKGROUND OF THE INVENTION 

Many emerging Internet applications are one -to-many or 
many-to-many, where one or multiple sources are sending to 
multiple receivers. Examples include the transmission of 
corporate messages to employees, communication of stock 
quotes to brokers, video and audio conferencing for remote 
meetings and telecommuting, and replicating databases and 
web site information. IP multicast efficiently supports these 
types of transmission by enabling sources to send a single 
copy of a message to multiple recipients who explicitly want 
to receive the information. This is far more efficient than 
requiring the source to send an individual copy of a message 
to each requestor (referred to as point-to-point unicast, in 
which case the number of receivers is limited by the band- 
width available to the sender). It is also more efficient than 
broadcasting one copy of the message to all nodes on the 
network, since many nodes may not want the message, and 
because broadcasts are limited to a single subnet. 

Multicast is a receiver-based concept: receivers join a 
particular multicast session group and traffic is delivered to 
all members of that group. The sender does not need to 
maintain a list of receivers. Only one copy of a multicast 
message will pass over any link in the network, and copies 
of the message will be made only ^cre paths diverge at a 
router. In this way, IP multicasting yields performance 
improvements and conserves bandwidth end-to-end. 

Multicasting has existed for several years on local area 
networks (LANs), such as Ethernet and Fiber Distributed 
Data Interface (FDDI). However, it was not until the devel- 
opment of IP multicast addressing, now an Internet standard 
(Request For Comment 1112), that such group communica- 
tion could be established across the Internet. 

Multicast communications across the Internet arc imple- 
mented on "MBone," short for Multicast Backbone, a virtual 
network that has been in existence since early 1992. MBone 
is referred to as a virtual network because it shares the same 
physical media as the Internet. It uses a network of routers 
(mrouters) that can support multicast. In portions of the 
Internet where multicast routers are not yet implemented, 
muhicast packets can be sent through Internet IP routers by 
encapsulating the multicast packets inside regular IP 
packets — referred to as "turmeling." It is expected that most 
commercial routers will support multicast in the near future, 
eliminating the need for the "tunneling" scheme. 

The key to understanding MBone performance is to focus 
on bandwidth. See "MBone Provides Audio and Video 
Across The Internet," by Michael R. Macedonia and Donald 
P. Brutzman, Naval Postgraduate School, available on the 
Internet at "ftp://taurus.cs.nps.navy.mil/pub/mbmg/ 
mbone.html." The reason multicast is bandwidth/efficient is 
that one packet can reach all workstations on a network. 
Thus, a 128-kilobit per second video stream (typically 1 to 
4 frames per second) uses the same bandwidth whether it is 
received by one workstation, or 20. However, such a mul- 
ticast stream would ordinarily he, prevented from crossing 
network boundaries (e.g., ordinary routers). These 
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boundaries, or firewalls, were implemented to prevent the 
entire Intemet from quickly becoming saturated with such 
streams. For this reason, multicast routers must implement a 
special protocol to allow controlled distribution of multicast 

5 packets. One such protocol limits the lifetime of muhicast 
packets. A second uses sophisticated pnming algorithms to 
adaptively restrict muhicast transmission. For the most part, 
the MBone now uses thresholds to tnmcate broadcasts to the 
leaf routers. The truncation is based on the setting of a 

10 time-to-live (TTL) field in a packet that is decremented each 
time the packet passes through an mrouter. For example, a 
TTL value of 16 would limit a multicast stream to a campus, 
as opposed to a value of 127 or 255, which might send a 
multicast stream to every subnet on the MBone (currendy 

15 about 13 coimtries). 

Controlling the transmission of muJticast packets can 
have a major impact on network performance. For example, 
a default video stream consumes about 128 Kbps of 
bandwidth, or nearly 10% of a Tl line (a common site-to-site 

20 link on the Internet). Several simultaneous high-bandwidth 
sessions might easily saturate the network linls and routers. 

When a host on an MBone-equipped subnet estabhsbes or 
joins a multicast session, it announces that event via the 
Internet Group Management Protocol (IGMP). A designated 
mrouter on the subnet forwards that aimouncement to the 
other mrouters in the network. Groups are disbanded when 
everyone leaves, freeing up the IP multicast address for 
future reuse. The designated mrouter occasionally poUs 
hosts on the subnet to determine if any are still group 
members. If there is no reply by a host, the mrouter stops 
advertising that host group membership to the other multi- 
cast routers. 

Mbone routing protocols are still being developed. Most 

^5 MBone routers use the Distance Vector Multicast Routing 
Protocol (DVMR); however, some researchers consider this 
method inadequate for rapidly-changing network topology 
because the routing information propagates too slowly. The 
Open Shortest Path (OSP) working group has proposed a 

^ multicast extension to the Open Shortest Path Link-State 
Protocol (OSPLSP), which is designed to propagate routing 
information more qtiiddy. With either protocol, mrouters 
must dynamically compute a source tree for each participant 
in a multicast group. 

45 MBone researchers are currently developing new appli- 
cations for multisender/multireceiver network traffic. Ses- 
sion availability is dynamically annoimced using a tool 
called sd (session directory), which displays active multicast 
groups. The sd tool also launches multicast applications and 

5Q automatically selects unused addresses for new groups. 
Video, audio and a shared drawing whiteboard are the 
principal MBone applications, provided by software pack- 
ages called nv (net video), vat (visual audio tool), and wb 
(whiteboard). The principal authors of these tools are Ron 

55 Frederick of Xerox, Palo Alto Research Center, Calif. USA 
(for nv), and Steve McCaime and Van Jacobson of the 
University of California Lawrence Berkeley Laboratory, 
Berkeley, Calif. USA (for sd, vat and wb). Each program is 
available in executable form without charge from various 

60 file -transfer protocol sites in the Intemet, and working 
versions are available for Sun, Silicon Graphics, DEC and 
Hewlett-Packard architectures. 

The following background information on IP multicasting 
will be useful in understanding the present invention. This 

65 information was taken from: "How IP Multicast Works," a 
draft paper by the IP Multicast Initiative (IPMI), available 
from Stardust Technologies, Inc., 1901 Bascom Avenue, No. 
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333, Campbell, Calif., 95008 USA, and firom the website: host group. IP multicast packets are sent using the same 

www.ipmulticast.c»m. "Send IP" operation used for unicast packets. 

IP Multicasting (Background) R*=*P''°? P"'^^^,^ complex Jo 

B\ & / receive packets, a user's host application requests member- 
IP multicast is an extension to the standard IP network- 5 ship in the multicast host group associated with a particular 
level protocol. RFC 111 2, Host Extensions For IP multicast session (e.g., "I want to review today's press 
Multicasting, authored by Steve Deering in 1989, describes conference with the President**). This membership request is 
IP multicasting as: "the transmission of an IP datagram to a communicated to the LAN router and, if necessary, onto 
'host group*, a set of zero or more hosts identified by a single intermediate routers between the sender and the receiver. As 
IP destination address. A multicast datagram is delivered to lo another consequence of its group membership request, the 
all members of its destination host group with the same receiving host network interface card starts filtering for the 
'best-efforts* reliability as regular unicast IP datagrams. The LAN-specific hardware (data-link or MAC layer) addresses 
membership of a host group is dynamic; that is, hosts may associated with the new multicast group address. WAN 
join and leave groups at any time. There is no restriction on routers deliver the requested incoming multicast packets to 
the bcation or number of members in the host group. A host 15 the LAN router, which maps the host group address to its 
may be a member of more than one group at a time." In associated hardware address and builds the message (for 
addition, at the application level, a single group address may example, an Ethernet frame) using this address. The receiv- 
have multiple data streams on different port numbers, on ing host network interface card and network driver, listening 
different sockets, in one or more applications. Multiple for these addresses, pass the multicast messages to the 
applications may share a single group address on a host. 20 TCP/IP protocol stack, which makes them available as input 

To support IP multicast, the sending and receiving end to the user's application, such as a video viewer, 

systems (nodes) and network infrastmcture between them Whereas an IP unicast address is statically bound to a 

(including intermediate routers) must be multicast-enabled. single local network interface on a single IP network, an IP 

The end node hosts are required to have: multicast group address is dynamically bound to a set of 

support for IP multicast transmission and reception in the local network interfaces on a set of IP networks. The 

TCP/IP protocol stack; multicast routers do not need to know the entire list of 

software supporting Internet Group Management Protocol member hosts for each group — only the groups for which 

(IGMP) to communicate requests to join a multicast there is at least one interested member on its subnet. Thus, 

group(s) and receive muhicast traffic; a multicast router attached to an Ethernet need associate 

network interface cards which efficiently filter for LAN <>°ly ^ ^^^^ Ethernet multicast address with each host 

data link layer addresses (e.g., MAC addresses) g">"P ^^^vrng a local member, 

mapped from network layer IP multicast addresses; Time -To-Live Field 

IP multicast application software, such as video confer- jp multicast packet uses a time-lo-live (TTL) field in 

encing. 35 the IP header to control the number of hops that the packet 

To run IP multicast on a LAN, only the above are aUowed to propagate. Each time a router forwards a 

needed— no routers need be involved. However, to expand packet, its TTL is decremented. A multicast packet whose 

IP multicast traffic to a wide area network (WAN) requires: yYL has expired (is 0) is dropped (without an error notifi- 

all intermediate routers between the sender(s) and cation to the sender). A local network midticsast reaches all 

receiver(s) mxist be IP multicast capable; 40 immediately-neighboring members of the destination host 

firewalls may need to be reconfigured to permit IP mul- group (the TTL is 1 by default). If a multicast packet has a 

ticast traffic. TTL greater than 1, a multicast router attached to the local 

It is also possible to implement an IP multicast-aware network lakes responsibility for Internetwork forwarding, 

switch which provides the same benefits as the multicast The datagram is forwarded to other networks that have 

router, but in a local area network. Without one, the multi- 45 members of the destination group. On those other member 

cast traffic would be sent to all segments on the local subnet. networks that are reachable within the time-to-live, an 

An IP multicast aware switch could be used to automatically attached multicast router completes delivery by transmitting 

set up multicast filters so that the multicast traffic is only the datagram as a local multicast. Thus, TTL thresholds in 

directed to the participating end nodes. multicast routers prevent datagrams with less than a certain 

. 50 TTL from traversing certain subnets; this provides a conve- 

IP MulUcast Addressmg ^.^^^ mechanism for confining multicast traffic to within 

IP multicast uses Class D Intemet protocol addresses, campus or enterprise networks. Several standard settings for 

those with 1110 as their high-order four bits, to specify TTL are specified for the MBone: 1 for local net, 15 for site, 

multicast host groups. In Intemet standard, "dotted decimal" 63 for region, and 127 for the world, 

notation, host group addresses range from 224.0.0.0 to 55 irMP 

239.255.255.255. Two types of group addresses are ^^^^ 

supported— permanent and temporary. For example, a per- The Intemet Group Management Protocol (IGMP) is used 

manent address of 224.0.0.1, has been assigned by the by multicast routers to learn the existing host group mem- 

Inlernel Assigned Numbers Authority (lANA), as the "all- bers on their directly attached subnets. The multicast router 

hosts group" used to address all IP multicast hosts on a eo does so by sending IGMP queries and having IP hosts report 

directly connected network, and 224.0.0.2 which addresses their host group membership. IGMP is an Intemet standard 

all routers on a LAN. The range of addresses between defined in RFC 11 12. 

224.0.0.0 and 224.0.0.255 is reserved for routing protocols IGMP messages are encapsulated in IP datagrams. IGMP 

and other low-level topology discovery and maintenance has only two kinds of packets: Host Membership Queries 

protocols. 65 and Host Membership Reports. 

To send an IP multicast datagram (packet), the sender To determine if any host on a local subnet belong to a 

specifies the IP multicast group address, which represents a muhicast group, one multicast router per subnet periodically 
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sends a hardware (physical or data-link layer) IGMP Host 
Membership Query to alllP end nodes on its LAN, asking 
them to report back on the host group memberships of their 
processes. This query is sent to the "all-hosts" group net- 
work address (224.0.0.1) and a TTLof 1 is used so that these 
queries are not propagated outside of the LAN. Each host 
sends out one IGMP Host Membership Report message per 
host group, sent to the group address, so that all group 
members see it. 

When a process asks its host to join a new multicast host 
group, the driver creates a hardware multicast group address, 
and an IGMP Host Membership Report with the group 
address is immediately sent The host network interface is 
expected to map the group address to local network 
addresses as required to update its multicast reception filter. 
Each host keeps track of its own group memberships, and 
when the last process on a host leaves a group, that group is 
no longer reported by the host. 

Periodically, the local multicast router sends an IGMP 
Host Membership Query to the "aU-hosts" group, to verify 
current memberships. If all member hosts responded at the 
same time, undue trafiSc congestion would result This is 
avoided by having each host delay the report by a random 
interval if it has not seen a report for the same group from 
another host As a result, only one membership report is sent 
in response for each active group address, although many 
hosts may have memberships. 

IGMP updates are used by multicast routing protocols to 
communicate group memberships to neighboring routers, 
thus propagating group information through the Internet. 
The bandwidth needed to transmit such group information is 
usually small compared to the multicast application traffic, 
so this propagation method is beneficial. 

Multicast Routing Protocols 

Multicast routing protocols present a more complex prob- 
lem. The Internet is composed of a plurality of subnetworks 
connected by routers. When the source of a message is 
located on one subnet and the destination is located on a 
different subnet, there must be some way to determine how 
to get firom the sotirce to the destination. This is the function 
of the IP protocol. Each host on the Internet has a unique 
address that identifies its physical location; part of the 
address identifies the subnet on which it resides and part 
identifies the particxilar host on that subnet Routers peri- 
odically send routing update messages to adjacent routers, 
conveying the state of the network as perceived by the 
particular router. This data is recorded in routing tables that 
are then used to determine optimal transmission paths for 
forwarding messages across the network. Because a unicast 
transmission is directed towards a single physical location 
that is specified by the host address, the routing procedure is 
relatively straightforward — i.e., binding of a single address 
to a single host 

However, routing multicast traffic is more complex. A 
muhicast group address identifies a particular transmission 
session, rather than a specific physical destination. An 
individual host is able to join an on-going multicast session 
by using IGMP to communicate this desire to its subnet 
router. A simplistic approach to sending data to multiple 
receivers would be for the source to maintain a table 
identifying all of the receiving subnets participating in a 
session, and to send a separate copy of the data to each 
receiving subnet However, this woiild be an extremely 
inefficient use of bandwidth, since many of the data streams 
follow the same path throughout much of the network. 
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New multicast routing protocols are being developed to 
address the problem of efficiently routing multicast traffic. 
Since the number of receivers of the multicast session can 
potentially be quite large, the source should not have to 

5 know all of the relevant addresses. Instead, the network 
routers should be able to translate multicast addresses into 
host addresses. The basic principle involved in muhicast 
routing is that all routers interact with each other to 
exchange information about neighboring routers. To avoid 

10 duplication of effort, a single router is selected (via IGMP) 
as the designated router for each physical network. 

For efficient transmission, designated routers construct a 
spanning tree that connects aU members of an IP multicast 
group. A spanning tree has just enough connectivity so that 

15 there is only one path between every pair of routers, and it 
is loop-free. If each router knows which of its links belongs 
to the spanning tree, it can copy an incoming multicast 
packet onto each of its outgoing tree links, generating only 
the minimum needed number of copies. Messages are rep- 

20 licated only when the tree branches, thus minimizing the 
number of message copies that are transmitted through the 
network. 

Since multicast groups are dynamic, with members join- 
ing or leaving a group at any time, the spanning tree must be 
dynamically updated. Branches in which no listing exists 
must be discarded (pruned). A router selects the spanning 
tree based on the network layer source address of the 
muhicast packet, and prunes that spanning tree based on the 
network layer destination address. 

30 

IP multicast routing algorithms generally follow one of 
two basic approaches, depending on the distribution of 
muhicast group members in the network. A first approach is 
based on the assumption that the group members are densely 
distributed throughout the network and bandwidth is 
plentiful, i.e., almost all hosts in the network belong to the 
group. These so-called "dense-mode" multicast routing pro- 
tocols rely on periodic flooding of the network to set up and 
maintain the spatming tree. Dense-mode routing protocols 
^ include Distance Vector Multicast Routing Protocol 
(DVMRP), Multicast Open Shortest Path First (MOSPF), 
and Protocol-Independent Multicast-Dense Mode (PIM- 
DM). 

A second approach is based on the assumption that 
45 multicast group members are sparsely distributed through- 
out the network and bandwidth is not necessarily widely 
available. It is important to note that the sparse mode does 
not imply that the group has only a few members, just that 
they are widely dispersed. In this case, flooding would 
50 unnecessarily waste network bandwidth and hence could 
cause serious performance problems. Thus, sparse mode 
protocols rely on more selective techniques to set up and 
maintain multicast trees. Sparse mode routing protocols 
include Core-Based Trees (CBT) and Protocol-Independent 
55 Multicast-Sparse Mode (PIM-SM). 

Multicast Apphcations 

Finally, many applications are now being developed to 
ensure real-time delivery so that, even with a time-critical 

60 application such as audio, participants perceive conversa- 
tions as if they are in real time. This is achieved by a small 
buffering delay to synchronize and resequence the arriving 
voice messages. For example, RTP, the Real-Time Transport 
Protocol, provides end-to-end network transport functions 

65 suitable for applications transmitting real-time data, such as 
audio, video or simulation data, over multicast or unicast 
network services. RSVP, the ReSerVation Protocol, supports 
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requests for a specific quality of service from the network for 
particular data streams or flows. RTSP, the Real-Time 
Streaming Protocol, is an application-level protocol for 
controlling delivery of data with real-time properties. 

lo summary, IP mullicasts enable many new types of 
applications over the lotemet, — e.g., transmission of corpo- 
rate messages to employees, communication of stock quotes 
to brokers, video and audio conferencing for remote meet- 
ings and telecommunicating, and replicating databases and 
website information. However, many separately-managed 
corporate or enterprise internetworks are now being installed 
based on switches, rather than routers. In order to integrate 
these switched subnets into the router-based Internet, pro- 
tocols are needed to ensure that select multicast traffic is 
transmitted onto the switched network, without generating 
excessive traffic or bottleneck, and that multicast traffic can 
efficiently pass the router/switch interface in a reliable and 
controlled manner. The present invention is directed towards 
enabhng the efficient transmission of multicast traffic in a 
switched network. 

SUMMARY OF THE INVENTION 

A first embodiment of the present invention is directed to 
a method for establishing switch connections in a switched 
communications network, in order to enable the transmis- 
sion of multicast packets. The switched network includes a 
plurality of hosts and switches connected by Unks, each 
switch having at least one network port connected to another 
switch and at least some switches having access ports 
connected to one or more hosts. Each host has a unique (e.g., 
physical layer) address. Each switch includes a connection 
database of valid coimections between different ports on the 
switch and a setup mechanism for estabhshing temporary 
connections between the different ports on the switch. A 
method of handling miilticast packets is provided, wherein 
a source switch receives a multicast packet on an access port 
from a source host, the source switch determines a group 
address from the multicast packet, and the source switch 
composes and sends a sender present message, containing 
the group address and source host address, to other switches. 
This inter-switch communication enables the switches in the 
network to learn which sender host has multicast packets to 
send to a designated group. 

A receiving switch receives the sender present message 
and determines whether a local host attached to one of its 
access ports wishes to join the group address identified in the 
sender present message. If yes, the receiving switch com- 
poses and sends a map message toward the source switch on 
a predetermined path, the map message containing the group 
address, the source host address, and the predetermined path 
between the receiving switch and source switch. 

When a switch receives the map message, it determines if 
there is an entry in its connection table for the group address 
and source host address, and if yes, it adds an outport to the 
entry identifying the port on which the map message was 
received. In this manner, connection table entries are made 
to include the path on which future multicast packets will be 
sent through the switched network. 

Alternatively, when a switch receiving the map message 
determines that there is no entry in its connection table for 
the group address and source host address, it adds an entry 
to its connection table for the group address, source host 
address, an inport identifying the port directed toward the 
source switch according to the predetermined path, and an 
outport identifying the port on which the map message was 
received. Again, this new entry in the connection table is for 
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future multicast traffic. The receiving switch may then send 
the map message on the predetermined path toward the 
source switch. 

Eventually, the switch receiving the map message is the 
5 source switch, at which point ail switches on the path to the 
various destination hosts (in the group) will have appropriate 
entries in their connection tables. Thereafter, each switch on 
the path switches multicast packets based on its connection 
table entry. 

IQ In addition, the source switch determines whether any 
local host attached to any of its access ports wishes to join 
the group address identified in the multicast packet. If so, the 
source switch adds an entry to its connection table including 
the group address, the source host address, and an outport 
identifying the port to the local host wishing to join the 
group (to receive the multicast message). 

If a host wishes to join a multicast session, the host will 
notify its local switch of this desire. The local switch then 
checks its connection table for an entry identifying the 
designated group address which the local host wishes to join, 
and if there is an entry, adds the access port on which the 
local host is connected as an outport for the connection table 
entry. If there is no entry, the local switch composes and 
sends a join group message to the other switches in the 

25 network, the join group message containing the designated 
group address and the local switch address. 

A switch receiving the join group message determines if 
a local host cormected to one of its access ports is the source 
host for the designated group address identified in the join 

3Q group message. If it is, the receiving switch sends a sender 
present message to the local switch. Depending on the 
protocol, the receiving switch may also pass the join group 
message to other switches in the network. The local switch 
eventually receives any sender present message (note there 

35 may be plural senders). In this manner, the local switch is 
notified of the source of any multicast session for the 
designated group address. 

In another embodiment, the switch receiving the join 
group message determines if a router is attached to one of its 

40 access ports. If so, the switch notifies the router that the 
switch wishes to join the group address identified in the join 
group message. This will enable all future multicast traffic 
designated for that group address to be sent from the router 
to the switch and the ultimate host in the switched network. 

45 A second embodiment is directed to a router/switch 
interface, for example enabling a switched-based subnet to 
send and receive multicast traffic to and from a router-based 
Internet. In this embodiment, a local switch determines if it 
has an attached local router, and if so, the local switch joins 

50 all or a subset of multicast group addresses. For example, 
this may be accomphshed by maintaining a database of 
receiving ports in each switch, for various multicast 
addresses. The receiver database would include the multi- 
cast group address, which may be a wildcard designating all 

55 muhicast groups, and the port on which the router is attached 
for sending or receiving multicast traffic. 

In another embodiment, a local switch receives a notice 
from a local host that the host vmhes to join a designated 
group address. If a connection entry exists for the group 

60 address and source host address, the local switch adds the 
port on which the local host is connected as an outport for 
the connection table entry. If not, the local switch composes 
and sends a join group message to the other switches, the 
join group message containing the designated group address 

65 and the local switch address. The other switches respond to 
the join group message with a sender present message as 
previously described. 
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If no response is received by the local switch, the local FIG. 13 is a flowchart of the multicastiag protocol method 

switch remembers the local host's desire to join the group, of the present invention showing multicast switch process- 

i.e., maintains the request in memory. Then, upon receipt of ing steps undertaken upon reception of an Unmap Up 

a future sender present message it will establish a connection message; 

and respond with a map message. 5 FIG. 14 is a flowchart of the multicasting protocol method 
In the above embodiments, the type of switch is not of the present invention showing multicast switch process- 
critical, e.g., it may be a packet-based switch, or a cell -based ing steps undertaken upon reception of an Unmap Down 
switch (ATM). The multicast packet transmitted by the message; 

switch is thus meant to include a standard multicast packet pIG. 15 is a flowchart of the multicasting protocol method 
or a multicast packet encapsulated or otherwise diAdded into lO of the present invention showing multicast switch process- 
messages such as cells. Also, it is envisioned that there will ing steps undertaken when a multicast switch detects a link 
be multiple senders in each session, and/or multiple sessions or port failure; 

occunring simultaneously. Pjq ^ flowchart of the multicasting protocol method 
. These and other features and benefits of the present of the present invention showing multicast switch process- 
invention wiU be more particularly described in regard to the ^ jug steps undertaken when a multicast switch detects the loss 
following detailed description and drawing figures. of a local sending host to a multicast group; 

BRIEF DESCWraON OF THE DRAWINGS /}°- " ^ ^ of the multicasting protocol method 

of the present mvention showing multicast switch process- 

FIG. 1 is an illustration of a prior art router network 20 i^g steps undertaken when a multicast switch detects that 

utilizing unicast communications; there are no more receivers for a multicast group; 

FIG. 2 is an illustration of a prior art router network FIG. 18 is a flowchart of the inulticasting protocol method 

utilizing multicast communications; of the present invention showing multicast switch process- 

FIG.3Ashows the relationship between LAN packets and ing steps undertaken by a proxy multicast switch upon 

IP packets; ^ reception of a Switch Leave Group message; 

nG.3B shows a more detafled relationship between LAN F^G. 19 is a flowchart flhistrating an example of a 

packets and IP packets; multicast communications session being set up between 

HG. 4 is an iUustrltion of a prior art router network ^""^'^^^ according to one embodiment of the 

showing a spanning tree distribution of multicast packets P^sent mvention, and 

within the network* F^G. 20 is a flowchart illustrating an example of a 

HG. 5 is an illustration of a switching network utilizing f ^^^^^f ^ communications session being joined by a local 

multicast switches and performing multicast communica- ^ "^^l^^^! ^^^^^ accordmg to one embodiment of 

tions according to various embodiments of the invention; present mvention. 

FIG. 6 is a detailed illustration of a multicast switch 35 DETAILED DESCRIPTION 
including a connection table according to various embodi- 
ments of the invention; Unicast vs. Multicast Communications 

FIG. 7A is a flowchart of one embodimert of the multi- ^^^^ applications send messages between one specific 

casting.protocol method of the present invention showing ^^^^ address and another host address over the network. An 

multicast switch processing steps undertaken upon the 40 1 r u - ♦ «^ ,.«^««t,*^«o «,^»i,^^^i^rr,r 

- , , , . J. 1 . . 1-.- * example of such a umcast communications methodology, 

detection of a local host sending packets to a new multicast ^ . ^. , . . ^. . 

^ ^ which sends messages separately, pomt-to-pomt, inom one 

sender to one receiver, is shown in FIG. 1. 

FIG. 7B is a flowchart of another embodiment of the , , . ^ 1 • ^ * 1 

... . 1 *!. J *• *• u In FIG. 1, mtemetwork 117 is a computer network com- 

multicasting protocol method of the present mvention show- . ' . ^ iivr n-f „«j 

^ *^ , . ^ J -* 1 ^ 45 pnsmg mterconnected routers 107-112 and sub-networks 

mg muluci^t switch piocessmg steps undertaken upon the P S jj,^ ^^^^^^ 

detecuon of a local host sendmg packets to a new multicast ^b-networks UJ-U6. Tlie internetwork, its routers, 

« . ^ 1 ^1 t . . ... J subnets, and hosts, are collectively referred to as the nel- 

HG. 8 IS a flowchart of the mulUcasUng protocol method ^^^j^ 100-106 may send messages between one 

of the present invention showing inulticast switch process- ^^^^^^ ^^^^ ^^^^^^^ 107_112 route the 

ing steps undertaken upon recepUon of a sender present ^^^j^^^^ ^^^^ internetwork between hosts, based on 

message; packet addresses. A host connected to a router via a subnet 

FIG. 9 is a flowchart of the multicasting protocol method ^ referred to as a local host for that router. For example, 

of the present invention showing multicast switch process- jocal hosts 101-103 on local subnet 115 are attached to local 

ing steps undertaken upon reception of a map message; router 109. 

FIG. 10 is a flowchart of the multicasting protocol method ^ ^ unicast example, suppose host 100 has a stream of 

of the present invention showing multicast switch process- y^^^ j^ta, labeled "ABC", which is to be sent to hosts 

ingstepsundertakenuponrcceptionof an IGMP Group Join 101-103 across the internetwork 117. To do so. host 100 

message; must place a frame of the "ABC" video data into a packet 

FIG. 11 is a flowchart of the multicasting protocol method so addressed for host 101, and send this packet to host 101. 

of the present invention showing multicast switch process- Host lOO must place another copy of the "ABC" video data 

ing steps imdertaken upon reception of a Switch Joua Group into a separate packet addressed for host 102, and send this 

message; packet to host 102, Host 100 must repeat the process with yet 

FIG. 12 is a flowchart of the multicasting protocol method another separate packet for host 103. The individual nature 

of the present invention showing multicast switch process- 65 and separate propagation of each "ABC" video data packet 

ing steps undertaken when a multicast switch detects that over the network is shown by three separate lines labeled 

there is no receiving host for a multicast group; "ABC for 101, "ABC" for 102, and "ABC for 103. Three 
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separate packets travel over the same link. The routers In the example, MCast router 129 has knowledge of local 

107-109 must create and transmit three packets (one for hosts 121-123 which have joined Group X, MCast router 

each receiving host) for every frame of video data. 129 only sends a single copy of each multicast packet onto 

Each single packet contains source and destination local subnet 136, and does so only if one of its local hosb 

address fields designating the sending and receiving host 5 121-123 is a member of (i.e.: has joined) Group X 

addresses, respectively. Routers 107-112 contain packet Likewise. MCast router 127 has knowledge of its local 

routing tables and routing algorithms which determine sending host 120 sending packets to Multicast Group X If 

where to send a packet, based on this addressing informa- another host, for example MCast host 125 on subnet 134 

tion. Each packet received by a router is examined for its joins Multicast Group X (e.g.: becomes a hslener), then a 

destination address, and then transmitted to the next router, 10 routing path within the MCast routers 127-132 is created for 

referred to as the next "hop", on the network towards its final the Group X mulUcast^ packets which are bemg sent from 

destination host. In this example, the "ABC" video data sender host 120 so that MCast router 131 receives the 

packets sent from host 100 are received by router 107, are multicast packets and routes them to subnet 134, for recep- 

examined, and are then sent to router 108. Upon packet tionby host 125. Similarly, if MCast host 126 on subnet 135 

reception, router 108 consults its routing table and routes 15 joms tiie multicast Group X. 

each separate packet to router 109. Finally, router 109 Advantages of multicasting over unicasting are clear from 

receives the "ABC* packets destined for hosts 101-103 and FIG. 2, when compared to FIG. 1. Less overaU network 

routes them to its local subnet 115 to be received by their traffic exists. Multicast packets are not duplicated in the 

respective destination hosts. network until a split in the stream of packets is needed to 

„ ^ ^ , 1 J * *u ^ 20 deliver packets to Specific host receivers at sepe rate routers. 

Router networks are slow due to the processmg required ^ , - i 

todetermmewhereeachpacketistobeient.Live.real.toe Multicast offers cost savmgs m netwo k l^^^^ r^ 

video data streams may require hundreds or thousands of "Uo^s more recemng hosts to jom to a g~«P smce 

packets in sequence. A separate individual "stream" of "^'work processing and bandwidth are conserved. Sender 

Jackets would have to be created for each receiving host. "ost processmg is also conserved since there is no need to 

Network bandwidth (the amount of packets or data sent « s"PP°« ^'^V sequential or concurrent unicast sessions, 

through any one point in the network) is greatly increased by Overview of Packet Formats 

the requirement for separate point-to-point transmissions a packet sent from a host onto the computer network is 

from a single sender to each of the separate receivers. If the actually a collection of binary digits ( I's and O's) arranged 

volume of packets were increased, or tiie number of receiv- ^ ^ specific order. As shown in FIG. 3A, there are different 

ing hosts grows too large (thus mcreasmg the number of icvclsor types of packets sent across networks. At the lowest 

separate packet transmissions), a point would be qmckly physical) level, called the Local Area Network (LAN) level, 

reached where network bandwidth and processing power of LAN packets as indicated at 171. ALAN packet is used 

routers would be exceeded and packets would be lost or ^ ^^^^ between the electrical hardware interfaces of 

"dropped". Unicast transmission of high-bandwidth data network devices (hosts or routers) located on a single 

streams thus allows only a limited number of participant communications link. A LAN packet has a LAN header 150 

senders and receivers due to these lunitations. ^ LAN data area 151. At a higher (network) level, IP 

FIG. 2 shows an alternative multicast communications packets, as indicated at 170 and by arrows 175, are encap- 

methodology. In multicast communications, one or more sulated in the LAN data area 151; the IP packet includes IP 

senders may transmit information to a group of receivers header 152 and IP data 153, which are used by higher level 

simultaneously. Each sending host sends a single copy of protocols and applications. 

each packet to a group address. Copies of packets are made pjQ 33 shows details of the LAN and IP packet structure 

only where network paths sptit or diverge. FIG. 2 shows an ^nd their inter-relationship. LAN packet 172 contains four 

example of multicast communications. header fields 154-157, a frame data field 158, and a CRC 

In FIG. 2, MCast host 120 executes a multicast-enabled 45 error checking field 159. Destination and Source Medium 

application, and routers 127-132 are multicast-enabled rout- Access Control (MAC) address fields 155-156 specify 

ers. Host 120 is called a "source" or "sender** host since it which network device attached to the physical network 

an originator of multicast packets sent onto the network. In medium is the destination and source of the LAN packet 

this example, suppose host 120 is transmitting muhicast 172, resepectively. A MAC address for any computer data 

packets of real-time video data containing picture content 50 communications device is unique and is assigned by the 

"ABC* as the multicast "session". The "ABC" packets are IEEE. LAN packets are used to transmit the Frame Data 158 

multicast onto the network, with each packet containing a field bits (i.e.:the IP packet information) across one link of 

destination address corresponding to the multicast group a computer network, between any two direcUy connected 

(called Group X in this example). The multicast packets are network devices (routers or hosts) attached to a network, 

sent to any hosts on the network which have joined the 55 Thus, a LAN packet only makes one "hop" on a link in the 

Mtilticast Group X session. network. Upon receptioci of a LAN packet, the network 

Hosts mayjoin groups (begin receiving multicast packets) device strips away the LAN header and trailer fields and 
and leave groups (cease receiving multicast packets) at any passes the Frame Data field bits 158 (i.e.: the encapsulated 
time, thus host group membership is dynamic. In FIG, 2, any IP packet 173) up to a "higher level" as indicated by arrows 
of hosts 120-126 may join Group X. Multicast-enabled 60 176 communications protocol where routing is determined 
routers 127-132 propagate the multicast packets over the based upon the IP header fields 161 and 162 which indicate 
network, with only one copy of each data packet being sent the source and destination of the IP packet. The Data Area 
across any one link of the network. Each MCast router field 164 contains the acmal information (i.e.: the video 
127-132 keeps track of which of its local hosts are joined data) that is being transferred between the software apph- 
(e.g.: listening as receiver hosts) to which multicast group 65 cations running on the sending and receiving hosts, 
sessions and which of its local hosts are sending hosts When a IP multicast packet is transmitted onto internet- 
sending packets to multicast group sessions. work 133 in FIG. 2 from a multicasting software application. 
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as from host 120 for example, the IP multicast packet is 
placed into the data field 151 of a LAN packet 171. The 
LAN packet is then sent from the sending host 120's 
network interface, onto the physical network medium, and is 
received by the computer network interface of the MCasl 
router 127. Upon reception of the LAN packet at the router's 
interface, the LAN packet information is stripped away, and 
the IP multicast packet information is examined to determine 
where the packet gets routed to next. 

As previously described, a multicast IP packet does not 
contain an IP destination host address, but rather contains a 
destination IP address of a multicast group. All IP multicast 
packets use Qass D IP addresses. In FIG. 3B, IP Multicast 
Address 174 (packet fields 165-169 ) corresponds to the 
Destination IP Address field 162 of IP packet 173, as shown 
by arrows 177. All IP Multicast addresses have "1110*' as 
their high-order four bits (IP Multicast Address fields 
165-168 ). This convention identifies an IP packet for a 
multicast group. Class D IP Multicast addresses can range 
from 224.0.0.0 to 239.255.255.255. Within this range, cer- 
tain addresses and sub-ranges are reserved for specific 
multicast uses or dedicated groups. The sub-range of 
addresses between 224.0.0.0 and 224.0.0.255 is reserved for 
multicast routing protocols and other uses. Address 
224.0.0.1 is an "aU hosts group" address, used to address all 
IP multicast hosts on a directly connected network, and 
224.0.0.2 addresses all routers on a Local Area Network 
(LAN). Dedicated groups exist as well, such as "NetNews" 
(224.0.13255). A dedicated group is used much like a radio 
or television station. Any Multicast enabled application that 
wants to "listen" to the news (Group NetNews), can join the 
group having the address of NetNews and begin receiving 
the IP Multicast NetNews packets. Protocols exist called 
"Session Announcement Protocol" and "Session Description 
Protocol** which allow multicast-enabled host applications 
to determine what groups have active senders at any point in 
time. 

Sending multicast packets from any multicast-enabled 
host is relatively simple. In FIG. 2, host 120 places the video 
data "ABC" into a IP multicast packet which specifies an 
appropriate multicast group destination address (Group X in 
this example), and then transmits the packet. As fiie IP 
packet moves along from host 120, to router 127, then to 
router 128, and to router 129, and finally to subnet 136, it is 
placed into and stripped out of LAN packet frames which 
surround the IP packets transmission over each network 
"hop". 

Spanning Tree For Router Network 

One method of routing multicast packets between routers 
is referred to as a spanning tree method. A spanning tree 
defines a tree structure where only one active path connects 
any two routers on the network. FIG. 4 shows the spanning 
tree, for example multicast group X as dashed lines. Once a 
spanning tree for a multicast group has been buih, a multi- 
cast router simply forwards each multicast packet to all 
interfaces that are part of the spanning tree, except the one 
on which the multicast packet originally arrived at. Using a 
spanning tree guarantees that a multicast packet will not 
loop within the network. E^tocols which implement span- 
ning trees are known in the networking community. 
However, a problem with the spanning tree solution is that 
it centralizes iraflSc on a small number of links and may not 
provide the most efficient path between a source and 
receiver. 

Switched Network With Controlled Multicast 
Traffic 

A particular embodiment of the present invention wiU 
now be described with reference to a switch-based network 
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connecting multiple IP subnets. In this embodiment, the 
switches utilize hardware (i.e., an ASIC) for fast switching 
of data packets based upon destination MAC address, after 
an initial connection set-up period which creates the neces- 

5 sary connection table entries in each switch on the path. 
These switches will implement IP flow switching of multi- 
cast packets, i.e., network or layer 3 switching, in that the IP 
group multicast addresses will map algorithmically to group 
MAC addresses. 

10 Although the switches described in this particular 
embodiment are packet switches, the invention is also appli- 
cable to the distribution of multicast packets and point-to- 
muhipoint connections over media such as an ATM cell- 
switched fabric. In either case, for efficient multicast packet 

IS distribution, the switch cloud is implemented as a tree rooted 
at the sender, providing point-to-multipoint switched con- 
nections so that only a subset of switches receive the 
multicast traffic. 

The switches do not act as multicast routers, neither 
individually nor collectively — they do not exchange multi- 
cast routing protocol messages. Rather, they detect multicast 
routers on their access ports to thereby enable hosts in the 
switch domain to both send and receive multicast traffic 
beyond the switch domain. Within the switch domain, a new 
"signal out and connect back" interswitch messaging pro- 
tocol is implemented for establishing connections through 
the switch domain for multicast traffic. 

To receive multicast traffic, a host in the switch domain 
must join a multicast group either dynamically (e.g., through 
the IGMP protocol), or statically by configuration. A host 
may join a group by sending a membership report to the IP 
group address in response to an IGMP query from its local 
switch. Some IP group addresses are reserved for well- 
known groups. Any host, whether or not a member of the 
group, may send to a group. 

A separate point- to-multipoint connection (i.e., path 
through the switch network) is set up for each sender and 
group address pair. When a new source (which may not 

4Q belong to the group) begins to send, the group-source 
information is signaled in a multicast switch protocol mes- 
sage along an "all switches" signaling chatmel which fol- 
lows a spanning tree. Each switdi that has local receivers 
(hosts) for this group, then unicasls a connection set-up 

45 message back toward the sender (source switdi) on a 
predetermined path; this path is a predetermined optimal 
path for the specific receiver switch and source switch pair. 
These connection paths arc merged at common (trunk) 
switches. Because the connection paths are generated in the 

5Q inverse direction (i.e., with respect to the actual multicast 
traffic), each switch with receivers is referred to as a "call- 
originating" switch. This mechanism avoids loops and 
enables multicast transmission similar to unicast transmis- 
sions. 

55 This mechanism of "signal out and connect back" works 
equally well for dense or sparse groups. Note that the packet 
distribution tree (the point-to-multipoint cormection that 
gets programmed through the switches on the path) is a 
second tree, independent of the panning tree used for the 

60 multicast switch protocol messaging. Also note that the 
package distribution tree can add branches when new receiv- 
ers join, without changing the rest of the tree. This stability 
is useful in supporting RSVP, which expects to periodically 
refi-esh reservations up the same branch that the original path 

65 messages went down on. 

As previously discussed, prior known multicast routers 
use a "flood and prune" mechanism known as RPM (reverse 
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path multicasting) to build trees. RPM is used with both 
DVMRP (Distance Vector Multicast Routing Protocol) and 
PIM-DM (Protocol-Independent Multicast-Dense Mode) 
multicast routing protocols. Each node must distinguish the 
"upstream" link using a routing database, where "upstream" 5 
means towards the packet source network. A router will only 
forward packets that arrive on the upstream link. This 
"reverse path forwarding" check prevents any loops from 
forming. 

In contrast, the switch domain of the present embodiment 10 
performs an inverted tree formation based on a leaf-initiated 
connection setup. This difference in tree formation is par- 
ticularly beneficial in that it allows host mobility in the 
switch domain. In the present invention, "upstream" does 
not imply a network routing hierarchy, but rather the switch 15 
port on, for example, the shortest path first calculation of the 
Link State Protocol (LSP). This LSP shortest path is pre- 
calculated and is already used for unicast path determination 
in the switches. As a result, the switches require less state 
information (less memory) to support tree set-up, than do 
routers. Note, for switches that do not have LSP, a backup 
flood style mechanism can be employed to accumulate the 
upstream path. 

SFPS Switching 

The present embodiment may be implemented as part of 
the Secure Fast Packet Switching (SFPS) network architec- 
ture available fi"om Cabletron Systems, Inc., Rochester, 
N.H., USA. This architecture is described in the product 
literature and in U.S. Pat. No. 5,485,455, which issued Dec. 
16, 1996, to Kurt Dobbins et al., and is hereby incorporated 
by reference in its entirety; it is also described in the 
corresponding PCT application published as WO 95/20850 
on Aug. 3, 1995. 

Secure Fast Packet Switching (SFPS) technology pro- 
vides the same or better reliability and security as routers, 
but with much greater performance and without an increase 
in cost. Switches avoid the complexities and costs of pro- 
viding multi-protocol routers. Also, switching systems pro- 
vides capabilities which routers do not, such as the ability to 
guarantee a quality of service (QOS) by providing dedicated 
switched paths through the network. 

Switching in SFPS networks is based on physical layer 
addresses — the source and destination MAC addresses. End- 
to-end connections are determined by a network manage- 
ment application that provides security and best path routing 
determinations based on a number of constraints. 

As will be described in more detail, switching uses source 
and destination MAC addresses which alone, or in combi- 
nation with an input port on a switch, form a unique 
"connection identifier" for any communication exchange 
between designated end systems. As an example: 

input port-2 

source MAC address=00:00:l D: 01:02:03 55 
destination MAC address=00:00:l D: 11:22:33 
together form a "tuple" bound to a specific uni-directional 
flow from a source address to a destination address. All 
packets that have this tuple are automatically switched i.e., 
(in a hardware) according to the operation of the switch. 60 

In traditional router devices discussed above, each packet 
is treated as an independent unit of data which is individu- 
ally processed at each router to obtain path determination. In 
contrast, with SFPS switching, this processing is done only 
with initial packets sent between the host sender and host 65 
receiver. Initial packets are decoded, and through use of a 
central or distributed directory of end system (host) con- 
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slraints policy, call attributes, location, paths, quality of 
service, etc., the connection is either rejected or accepted. If 
accepted, the path is determined and setup. At that point, 
switches along the path are "programmed" to allow subse- 
quent packets on this specific "connection" to be quickly 
switched (i.e., in hardware — ASIC). In either case, subse- 
quent packets are either switched or discarded without 
having to reapply aU of the security and access control and 
routing path determination logic. 

The above switching network is referred to as a "flat 
network", since packets remain unchanged throughout their 
propagation aaoss the switching network. This switching 
technology may be constructed as either software objects 
which exist in embedded devices as firmware, as software 
objects which arc part of an application on a commercial 
computer system, or as application specific integrated cir- 
cuits (ASIC), or fimctionaUy equivalent hardware compo- 
nents. Generally, a switch is a self-contained piece of 
hardware having multiple ports to which network cables 
connect, and includes software and a processor for executing 
the same. 

In FIG. 5, a switching network 28 is shown comprising 
multicast-enabled (MCast) switdies 14-19 inter-connected 
with network links 20-27. The network links 20-27 connect 
to network ports on each switch. Access or host links 10-13 
allow the multicast-enabled (MCast) hosts 1-6 to connect to 
their respective local MCast switches 14, 16 or 18. MCast 
switches 14-19 switch packets transmitted between sending 
and receiving hosts 1-6. Other hosts may be attached to 
switches 14-19, but are not shown for brevity. 

The data communications medium of host links 10-13 
and network links 20-27 may be any type which supports 
packet data communications. Each host 1-6 has a unique 
network address. In this example Ethernet addressing is 
used. The scope of the invention is not limited to specific 
types of addressing or data communications medium. Other 
types of network communications and addressing may be 
used, such as Asynchronous Transfer Mode (ATM), Inte- 
grated Services Digital Networks (ISDN), Fiber Distributed 
Data Interface (FDDI), Token-Ring networking. Systems 
Network Architecture (SNA), or Appletalk networking 
schemes, for example. 

A specific example of packet switching according to one 
embodiment of the present invention now be given. FIG. 6 
shows MCast switch 14 from FIG. 5 in more detail. Packets 
are transmitted to and from switch 14 over network links 20 
and 24 (connected to network ports 33 and 32 ) and over host 
links 10 and 11 (connected to host ports 30 and 31). 
Connection table 34 maintains currently active connections 
in memory during switch operation. Each connection is 
equivalent to one entry (row of values) in the table, includ- 
ing a "tuple" and its associated Out Port(s). The "In Port" 
column of connection table 34 designates input ports 
(network or host) on which packets arrive. The "Dest. 
MAC" and "Source MAC* columns refer to the destination 
and source MAC addresses for packets being switched. The 
first three columns (In Port, Dest. MAC and Source MAC) 
of a connection form a connection tuple. The "Out Port" 
column lists the output port(s) (network or host) to which 
packets are switched to when a packet tuple matches a 
connection tuple in the connection table. When a packet 
arrives at switch 14 on any link (network or host), the 
packet's mple is looked up in the connection table 34, and 
the packet is switched to the designated output port(s). 

In FIG. 6, suppose LAN packets 35 and 36 (shown with 
only their destination and source MAC address fields visible 
for purposes of this explanation) arrive at multicast switch 
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14 on host ports 30 and 31, respectively. LAN packet 36 is 
a imicast packet, since both its source and destination MAC 
addresses correspond to host addresses (hosts 1 and 6, 
respectively) from FIG. 5. The connection table 34 indicates 
that the tuple for LAN packet 36 (In Port=31, Dest. MAC« 
08:4E:13:09:2A:06, Source MAC=08:4E:13:45:2A:02 ), the 
packet wiD be switched to network output port 33. 

The last ccimection in connection table 34, labeled 37, 
corresponds to a multicast group connection and designates 
muhiple out ports. LAN packet 35 is a multicast packet, 
since its destination MAC address is an group address 
(beginning with 01:00) which does not correspond to any 
host on network 28. When multicast packet 35 arrives at 
switch 14, based on its tuple value, it will be switched to out 
ports 32 and 33. 

Components of the Multicast Solution 

Multicast is a fundamental networking paradigm and 
requires additional mechanisms beyond what is present for 
unicast connection. New components include: the provision 
of a reliable signaling channel to announce information to 
other switches additional protocol for point-to-multipoint 
connection set up; an IGMP (Internet Group Management 
Protocol) state machine to learn when hosts want to join 
multicast groups; the handling of attached multicast routers; 
distribution of group membership information; and methods 
for setting up and tearing down multicast packet distribution 
trees. 

Reliable Delivery 

Multicast switch protocol (SP) messages are sent over a 
transport layer called "reliable delivery." When reliable 
delivery is called by an application layer to send a message 
payload out one or more ports, it allocates a packet buffer, 
initializes it with a MAC header, SP header, and Reliable 
Delivery header, then copies in the application payload. It 
assigns a unique identifier to the message, which embeds 
that switch's primary MAC address, and sets this identifier 
into the Reliable Delivery header. 

Reliable dehvcry sets a timer (on each outport the packet 
is sent) and waits for acknowledgments from neighbors. An 
acknowledgment shuts off that port's timer. If a timer 
expires it resends the message on that port and resets that 
timer, repeating this every five seconds for up to six retries. 
It releases the packet buffer after all acknowledgments have 
been received or failing that, after one minute. 

If reliable delivery receives a message it did not originate, 
it sends an acknowledgment and delivers the message pay- 
load to the given apphcation layer. If it receives a message 
it did originate, i.e. a "known" message, it does not pass the 
message up to the apphcation layer but treats it as an 
acknowledgment instead. Any further copies of the known 
message arc disregarded. Therefore, loops are immediately 
damped and rehablc delivery can be used to flood signal 
messages to all switches. 

Rehablc delivery provides three interfaces to the appli- 
cation layer to send messages: 

(1) Deliver — sends a message one hop to neighbor 
switches, 

(2) Announce — sends to all switches, either on the 802. Id 
spanning tree or by flood, 

(3) Direct — sends along a path to a target switch and only 
passes the message up to the application layer in the 
target switch. 

Multicast Signal Channel 
Messages announced through rehable dehvery use the 
802.1d spanning tree. Currently the spanning tree is kept 
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only as a database and packets are forwarded through host 
code in each switch. 

In this embodiment, implementing the signal chaimel in 
the switch requires only a single connection entry. All links 
^ in the spanning tree for that switch are in the outport mask 
along with the host control port. The hardware source port 
checking is disabled so that the switch forwards a packet to 
all Unks in the outport mask except the link on which the 
packet arrived. In the multicast signal channel, packets are 
forwarded strictly along the spanning tree, but it would be 
possible during a topology change for a packet to arrive on 
a link not on the spanning tree and cause a loop. To prevent 
looping the source port is checked in host code to validate 
arrival on the upstream spanning tree link, and if not 
validated, the connection entry is removed and the padcet 
dropped. A snooping mechanism may be implemented to 
leara the upstream spanning tree link for each remote switch. 

Multicast Router Detection and Handling 

20 

On any given switch access port there may be one or more 
multiple multicast-capable routers. These routers may be 
upstream or downstream at any time with respect to any 
given multicast packet distribution. Downstream multicast 
25 routers must be detected in order to forward multicast 
packets to them; upstream multicast routers must be detected 
to receive multicast packets from them. Detection is done by 
passive snooping. 

It is easy to detect the presence of active attached multi- 
cast routers. For DVMRP-capable multicast routers, the 
presence of the router on an access port is detected be 
receiving a Neighbor Probe Messages sent to the "All- 
DVMRP-Routers" group address. For PIM-capable multi- 
cast routers, their presence is detected by receiving PIM 
Router-Query messages on the "All-PIM-Routers" 
(224.0.0.13) group address. 

A router is supported as if it were an attached host which 
had joined all multicast groups. Even though the switch does 

40 not issue IGMP queries on the router hnk, and even though 
multicast routers do not send out IGMP membership reports 
to join the "All-DVMRP-Routers" or "AU-PIM-Routers" 
groups, these routers hear eadi other on these groups 
because routers are impliciUy joined to aU multicast groups. 

45 In other words the switch fabric looks to attached routers as 
if it were a shared media wire. 

Therefore it is not necessary for a switch to be recognized 
as a "neighbor" by a multicast router. On behalf of hosts 
anywhere in the dDmain, a switch (1) sends out multicast 

50 packets onto router links and (2) receives in multicast 
packets from routers because IGMP reports are sent on 
router ports to join groups on behalf of those domain hosts. 
Any multicast generated from within the switch domain is 
sent to all attached multicast routers and any multicast 

55 packets sent into the domain from a router will transmit to 
other multicast routers as well as any directly-attached hosts 
which had akeady joined that group. 

Multicast Switch Protocol 

60 

The signahng protocol used for multicast consists of 
Switch Protocol (SP) messages based on the "81 FD" 
ethertype. SP messages are sent by and to other switches and 
only through reliable delivery. Some messages are 
65 announced to all switches simultaneously, and some mes- 
sages are dehvered one hop to neighbors or directed to a 
given neighbor switch. 
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Message types are: 

Router Present, announced to say detection of a multicast 

router attached; 
Groups Present, directed to router-attached switch to 

inform of locally joined groups; 
Senders Present, announced when new multicast sender 

appears on an access port, or directed with list of 

senders in response to a Switch Join; 
Switch Join, announced when a multicast group initially 

joins a switch; 
Switch Leave, announced when a group leaves the switch; 
Map, delivered to neighbors along a path to set up a 

connection; 

Unmap, delivered up the inport or down the outports of a 

connection to tear it down; 
Assert, delivered to neighbors when there is contention to 

send on a shared link. 

IGMP State Machine 

A switch runs a separate IGMP state machine on each of 
its access ports. For ATM, this may mean on each virtual 
access port, representing an SVC or LANE emulated LAN. 
The state machine sends IGMP membership queries peri- 
odically out each port, and listens for IGMP membership 
reports (called "joins") to maintain a database of local 
receivers per port. This database is held in a table and allows 
ports to be joined statically as well. It a timer expires without 
any reports, the switch knows there are no receivers for that 
group and can stop forwarding multicast flows out that port. 

IGMP Active Senders Problem 

The IGMP membership report, sent in response to a query, 
is addressed to the group multicast address. Suppose a given 
host reports and that host is also a sender to the group and 
therefore the source of a connection to other receivers in the 
domain. In this case the membership report is forwarded out 
all those receivers' ports and bearing this report causes other 
hosts to reset their timers instead of responding to the local 
queries on their Hnks. Switches would not know if receivers 
were still there. Delaying queries on those access ports 
having active senders would reduce the problem but not 
solve it. A switch must either: (1) temporarily take down 
connections and throttle multicast flows to check for mem- 
bership; or (2) assume membership remains and send out 
flows that are no longer wanted. 

One way to avoid this problem is to have the IP protocol 
field distinguish IGMP packets, as part of its flow identifier 
connection key. Then, a source can recognize its own 
packets. 

Another solution takes down connections by "sniffing" 
each access port for the duration of a "query interval" of 
about 10 seconds. Sniffing walks the multicast connection 
tabic and, for any connection having that inport, substitutes 
the host control port for the outport(s), before sending out an 
IGMP query on the port. Existing sender flows arriving on 
the sniffed port are forwarded through the CPU (central 
processing tmit on the switch) rather than switched in 
hardware. If a new sender appears on a sniffed port the 
Senders* Present announcement is made to all other switches 
and the senders *s multicast packets are forwarded by the 
CPU. Should membership to a given group be reported on 
the sniffed port, sniffed connections for that group are 
immediately restored to their original outports. FinaUy, 
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when the query interval expires, the port is "unsniffed" and 
all sniffed connections are restored. 

If a multicast router exists there is a contention as to 
whether the router or the switch is the designated querier. 

5 IGMP specifies that the lowest IP address wins. If hosts also 
exist on this port which may re^ond to queries from the 
router, the switch must not allow host membership reports to 
be switched through it — this would silence other receivers of 
that group &om responding to local queries on their access 

10 ports. The problem could be avoided by a topology 
restriction — no multicast senders allowed on links with 
multicast routers — enforced by the switch accepting only 
PIM or DVMRP group packets in on such a link. 

However, another solution is not to restrict topology. If 
the switch hears an active router it defers querying to the 
router; when a switch hears the query from a router it sniEEs 
that port. This mechanism would appear to leave a window 
whereby a membership report could sHp through before a 
congested switch hears the query. This is generally not a 
problem in practice because IGMP specifies host member- 
ship reports are delayed at least 1 second and multiple 
queries must go unanswered before group membership is 
lost on a port. A port can also be configured to not query by 
setting the query interval in the MIB for the IGMP Cache 

^ l^ble to zero. 

Multicast Database Service 

Multicast maintains two distributed databases readable 
through SNMP (Simple Network Management Protocol). 
Each switch keeps a database of senders in a muhicast 
connection table, each active local sender being represented 
with at least a filter connection, and each switch also keeps 
a database of local receiver ports in a table. Senders are 
discovered when they send and are removed through age 
out. IP receivers are either configured statically or main- 
tained through the dynamic IGMP query protocol. This 
database docs not require replication nor highly dynamic 
refresh because the initial appearance of both senders and 
4Q receivers is reliably announced to aU switches, and if the 
switch resets its senders and receivers reappear and are 
reannounced. 

Of course a switch cannot aimounce the disappearance of 
its senders and receivers if it reboots. Because of this and 

45 possible topology changes that could occur during physical 
wire changes or on busy or resetting switches, it is possible 
to form a hole or loop. Aging mechanisms take care of holes. 
A switch detects a loop by receiving a multicast flow packet 
on a port other than ttie connection inport. Upon detecting 

50 such a "mobile sender** the switch would tear down the old 
connection which fixes the loop. Although these mecha- 
nisms dean up bad connections, rerouting around such 
problems may require that information held locally in the 
multicast database be distributed again to reset connections. 

55 Thus each switch reannounces its database every few min- 
utes. 

Local Senders Database 

Each switch maintains knowledge of its local senders. 

60 This database (see Table 1) is indexed by multicast group 
and host source address and holds the souirces that have 
appeared on this switdi and the inport on which the source 
host appeared with the create time of the entry. This infor- 
mation is periodically reannounced in a Senders Present 

65 message in case any potential receivers initially failed to 
connect. 
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TABLE 1 




Lxcal Senders Database 






Group 


Source IP Source MAC 


Inport 


Created 


224.3.3.3 


134.141.403 1:2:3:4:5:6 


2 


1:15 



Local Receivers Database 

Each switch maintains knowledge of its local receivers. 
The IGMP query state machine builds in each switch a local 
database (Table 2) of miilticast groups which exist on each 
interface of that switdi. Alternately, group membership may 
be statically configured. When group membership initially 
occurs on a switch, this information is distributed to all other 
switches by sending an SP Switch Join announcement and it 
is periodically reannounced for aU groups joined at that 
switch in a Groups Present message. 



TABLE 2 




Multicast Receiveis Database 


Group 


Port Receivers Exist? 


224.3.3.3 


2 yes 



Joined Groups Database Actions 

Router-attached switches maintain knowledge of all 
groups in the domain. Groups joined at any switch in the 
domain must be known to any switch with attached multi- 
cast routers to permit joining these groups up to the router. 
This is done by answering IGMP queries generated by the 
router with a membership report for each group known in the 
domain. When a switch first joins a group or leaves a group, 
it announces this on the signal channel to all switches. 
Periodically this information is reannounced — the Groups 
Present message. This is necessary so the switches with 
attached multicast routers remember this information to 
continue joining or to stop joining up to the router when the 
last switch leaves the group. 

Connection Set Up 

When a source host, which may not even belong to a 
group, first sends multicast packets to a group address, there 
is no existing connection at the ingress (local) switch and the 
first packet is "call processed." The switch installs either a 
filter connection, to keep following packets from clogging 
its host control port, or installs a connection out its access 
port(s) if there are already local receiver port(s) joined to the 
group. It then announces a Senders Present message on the 
signal channel. (Note: a Senders Present message may also 
be sent directly to a switch which later joins the multicast 
group, in rei^onse to the Switch Join announcement.) 

This Senders Present message contains the group, the 
source host, and the source switch identity. Any switch 
having local receivers for thai group attempts to set up a 
connection to the source host. Such a switch, although it is 
a call-originating switch, is an egress switch for the con- 
nection. To set up the connection it retrieves the precalcu- 
lated shortest path toward the ingress switch from the LSP 
database. (A backup alternate mechanism to determine a 
path, is discussed below imdcr "Sender Fan Out"). 

The call-originating switch then reliably delivers a Map 
connection set-up message one hop up the path's upstream 
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link toward the ingress switch. This Map message contains 
the full path. The receiving switch named as the next hop on 
the path processes the Map. If it has no connection for that 
(group, source) it sets one up and forwards the Map up the 
5 path. If it already has a connection it simply adds in the 
outport on which it received the Map message and does not 
forward the Map. The final result of this process is a 
point-to-multipoint connection rooted at the source host out 
to all receiver active links. 

10 

Connection Set Up — At An Egress Switch 

If a switch detects through IGMP a group joining on a new 
access port and there are already connections installed to the 
group, the switch adds that port to these coimections. These 
connections could source from local senders on its other 
access ports, or remote senders on a network inport. 

If a switch hears a Senders Present announcement for a 
group it has not joined it disregards the message. If it has 
joined that group it checks to see if it already has the 
connection set up for that {group/source} key, and if so it 
assures the connection outports match the ports in the 
multicast receivers database. If there is no existing connec- 
tion it sets one. It uses the LSP database to get the inport, 
which is the link on the path to the sending switch, and gets 
outports from the multicast receivers database. Then it 
initiates a connection set up Map message upstream on that 
path. 

Connection Set Up — Along Tree Branch 

30 

In the multicast tree being formed, some switches he 
along branches and some switches are located at branch 
points of the tree. First consider a switch which lies along a 
branch, on a link with only one peer. This is a switch which 

35 receives a Map message in which it is the next switch along 
the path in the message and which does not aheady have an 
existing connection installed with this {group/source} key. 
The switch installs a new connection for its point of the path, 
with the inport being its upstream path link and the outport 

4Q being the port on which the set-up message was received. It 
then forwards the Map up the path toward the next switch. 

Connection Set Up — ^At Tree Branch Point 

A switch that will be at a branch point in the multicast tree 
45 being formed receives a Map message in which it is next on 
the path and it already has a connection installed with this 
{group/source} key. First it validates the message arrival 
port — there would be a "mobile sender** or a topology error 
condition if the Map arrival port were the inport of the 
50 pre-existing cormection. If there is no error, the message 
arrival port is added to the outports in this existing connec- 
tion and the set-up process terminates. There is however 
special handling if a switch receives the message on a link 
on which it has multiple peers. 

Connection Set Up — Filtering On Multi-Switch 
Links 

A switch which receives the Map message but is not 
included on the path in the message, and does not have the 

60 requested connection already installed, installs a filter con- 
nection. This is important for switches on multi-switch links 
(such as FDDI loops) since uninvolved switches (i.e., 
switches not included in the tree being set up) are protected 
from congestion before the multicast flow begins. This is 

65 one reason the set-up message is broadcast hop-by-hop 
upstream, rather than simply unicast to the next peer switch 
on the path. 
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Connection Set Up — ^Designated Sender on Multi- 
switch Links 

When more than two switches exist on the same link, 
whether an FDD! or cthemet link, a mechanism is necessary ^ 
to prevent sending duplicate packets downstream. This 
problem is rare, but could occur when receivers, connecting 
up toward a given multicast source ask for LSP paths at 
different times, and the LSP paths relumed name different 
switches as sender on a shared link. A similar problem would 
exist if different redundant links between the same switch 
pair were chosen for the connect up paths. A mechanism 
must assure that only one switch forwards on to the common 
link for a given tree. 

This problem also occurs in the legacy world among js 
multicast routers. To solve it PIM routers exchange PIM 
"Assert" messages. This exchange determines the lowest IP 
addressed router on the shared link which is then designated 
to be the sole multicast sender on that link. Switches require 
similar protocol; the question is what basis should be used 20 
to designate the sole sender. It is arbitrary to choose simply 
lowest or highest address sender, and protocol would be 
required anyway among the subset of requested senders. A 
basis of "closest to the source" is iiseless; it is unlikely that 
if two switches on a multi-switch link are picked by LSP, 25 
that one is much closer to the source than the other. 

One solution is to choose the "first connected" sender 
switch — which is enabled by maintaining timestamps on 
connections. A switch having a connection with the common 
Unk as an outport considers itself the designated sender on 30 
the Hnk. This switch detects a multiple sender condition for 
that {group/source} key when it receives on that common 
link, either: (1) a Map request with that key which names not 
it but another switch as next switch in the path; or (2) a 
multicast packet having that key; or (3) an Assert message. 35 
When the condition is detected, the switch sends an Assert 
message out the common link in the attempt to be the only 
designated sender. The Assert contains its switch identity, 
the {group, source} key, and the connection timestamp. 
Since different {group, source} trees can have different 40 
designated senders, this mechanism distributes the load over 
multiple switches. 

A switch receiving an Assert that considers itself the 
designated sender for that key does nothing if it has the older 
connection, i.e. its timestamp is earlier than that in the Assert 
message. If its connection is younger it cannot remain 
designated sender. It removes the common link from the 
outports of that connection; if no outports remain it sends an 
Unmap up the connection inport as discussed below. 

50 

Connection Tear Down 

The packet distribution tree of a multicast cormection is 
distributed across switches. Multicast connections form 
trees rather than simple paths and the loss of a switch or link 
may affect only a small part of the tree. An individual switch 
knows only the mapping of inport to outport(s) for each 
muhicast connection it has installed. There are three cases 
where branches of a multicast tree must be torn down; one 
occurs due to a topology change; another occurs when a 
receiver leaves a multicast group; and the third occurs when 
a sender ages out. 

Connection Tear Down — ^Topology Change 

A switch may detect topology changes a number of ways. 65 
Physical rewiring could create a loop or cause receipt of a 
muhicast flow packet on a port other than its inport. More 
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typical is the detection of a lost switch or hnk. A switch 
discovers local losses through electrical down or switch 
hello failure. A switch is told of remote losses through 
signaling initiated by a switch local to the change. This 
signaling is done via LSP (Link State Protocol) topology 
exchange, but could be done for multicast by an announce- 
ment message on the signal charmcL Since multicast con- 
nections do not retain associated paths, when a Link or switch 
is lost, switches adjacent to the change control the tear down 
and rerouting. 

An adjacent switch above a bad link removes that link for 
the outports of any of its multicast connections. Any con- 
nection with the lost link as its only outport becomes a filter 
connection and the switch initiates an Unmap message up to 
its upstream neighbor, removing the filter when the Unmap 
is acknowledged. Unmap messages propagate up to the next 
merge point or to the sender switch. 

An adjacent switch below the bad link removes all 
multicast connections having that link as inport and for each 
such connection sends an Unmap message down to all 
neighbor switches. If a switch has local receivers to the 
group of any affected connection, it attempts to reroute and 
asks LSP for another path to sender. If that path provides a 
new inport it initiates a new connection by sending a Map up 
that path. 

A switch sending on to a FDDI ring or other multi-switch 
common link miist know when multiple downstream 
switches receive over the common link when tearing down 
connections. This may require another Assert message. 

Connection Tear Down — Switch Port Leave 

The switch knows when the last receiver to a group on an 
access port leaves that group, by detecting the lack of IGMP 
membership reports in response to queries. It removes that 
port from lie outports of any multicast connection for that 
group- Some of these connections may thereby become filter 
connections because there are no other outports. Any filter 
connectioii with a local sender is immediately removed; if 
that sender is still active the filter connection would gel 
immediately reinstated as a new sender. For any filter 
connection with a remote sender, i.e. attached to some other 
switch, the switch sends an Unmap message up the inport 
toward its upstream neighbor and removes the filter when 
the Unmap is acknowledged. 

Unmap messages continue to propagate up to a merge 
point or to the sender switch as follows: each next upstream 
switch removes the Unk on which it receives the message 
from the outports of its connection entry and, if no outports 
remain, forwards the Unmap up the inport of the connection. 
Each switch acknowledges receipt and removes its filter 
connection when acknowledgment is received. Thus, the 
affected branch of the tree is torn down reUably hop-by-hop 
until the ingress switch or an upstream merge point is 
reached. 

If the port is also the last port on that switch belonging to 
that group, the switch announces a Switda Leave on the 
signal channel. This is so that router attached switches may 
know when the last switch leaves the group and can stop 
joining the group to the router 

Connection Tear Down — Sender Age Out 

Inactive multicast connections are aged out for example 
after 10 minutes. Age out is generally necessary because of 
hardware fimitations — only a given number of muhicast 
outport masks are supported in the switch. A switch uses for 
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example a five minute interval timer to age out connectioos 
sourced from its locally attached hosts. Before removal a 
connection is sampled for an interval by adding the host 
control port to its outports. If a sender is still active that 
connection is not removed. 

If the sender is inactive an Unmap message is sent out 
each outport of the connection to downstream neighbors and 
the connection is deleted. Each switch receiving the Unmap 
removes the connection for the given {group/source) key. 
The Unmap message propagates down to the egress 
switches. 

Sender Fan Out 

Consider a switch domain not running LSP. When a new 
local multicast source appears and is call processed, the 
switch sends an SP message to each neighbor imtil each 
neighbor acknowledges that message. This message 
includes a source route field in which it places its outgoing 
switch link identifier. Each neighbor switch notes the link on 
which it first hears the message, fans this message out to all 
neighbors, adding its outgoing switch link identifier. The 
message thus accumulates a source route as it fans out A 
switch receiving this message and which has local receivers 
to the group can use the source route to define "upstream" 
and initiate connection set-up. 

A mixed environment of LSP and non-LSP switches 
would require further modification to the connection setup 
protocol so that non-LSP switches could connect up to the 
nearest LSP switch which would then add its SPF path to the 
source route to continue the connection set up toward the 
source. 

Related Applications 

In the present embodiment, a single packet distribution 
tree is set up from a given sender to all receivers in the group 
defined by a designated IP group address. In networks 
employing work groups, i.e., a logical (as opposed to 
physical) domain of hosts at various locations on various 
subnets, a user may wish to run several instances of an 
application (such as a whiteboard or video conference), 
where each instance involves a separate set of hosts in the 
same domain. Each instance would thus have its own group 
IP address, associated with the workgroup(s) by configura- 
tion. A description of workgroup domains is contained in 
copending and commonly-owned U.S. Ser. No. 08/501324 
filed Jul. 12, 1995 by K, Dobbins et al, and hereby incor- 
porated by reference in its entirety. 

Also, the present embodiment can be integrated with a 
network utilizing virtual LANs (VLANs), which again are 
logical groups of hosts on various subnets. A "multicast 
VLAN" can be configured on a port basis through VLAN 
management. The VLAN is named according to the asso- 
ciated multicast group IP address, such as IP.224.0.1.2. Ports 
can be joined to multicast groups statically (without running 
IGMP) by assignment of the port to the multicast VLAN. 
Ports on which a group is joined through IGMP are also 
remembered in that VLAN. A description of VLAN man- 
agement is contained in copending and commonly owned 
U.S. Ser. No. 08/559,738 filed Nov. 15, 1995 by K. Dobbins 
et al., and hereby incorporated by reference in its entirety. 

Static configuration is useful in applications such as disk 
mirroring. For example, consider a set of dispersed servers 
which replicate a database on their disks. Each server port is 
configured to the multicast VLAN and joins the group. This 
allows a client anywhere in the domain to update all servers 
simultaneously. 
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Flow Charts 

The flow charts shown in FIGS. 7-20 illustrate the prior 
described message handling in a switching network such as 
shown in FIG. 5. Generally, each flow chart represents the 
steps necessary to handle a specific multicasting event or 
message. After a description of the flow charts, an example 
muhicasting session between various hosts will be described 
to aid in the understanding of the invention. Various alter- 

^ ations may be made to the processing disclosed herein by 
those skilled in the art while maintaining the same overall 
desired effect. These alterations and modifications are meant 
to be within the scope of the invention. 

FIG. 7A shows the general processing steps a switch 
performs upon detection of a local host transmitting a new 
session of multi-cast packets for a new group onto the 
switching network. The sending host is referred to as a 
source, and corresponds, for example, to MCast host 1 in 
FIG. 5. In step 200, the source host's local switch (source 

I switch) detects the packets for the Multicast group. The 
source switch may, for example, correspond to MCast 
switch 14 in FIG. 5. The source switch checks (step 201), via 
IGMP, for any other local host receivers on any other local 
subnets (i.e., subnet shown as host link 11 in FIG. 5) which 

; may be requesting to join the new multicast group, and 
establishes a coimection in the connection table (step 202) 
for this multicast group for the requesting local host output 
ports. If there are no local host receivers, the source switch 
establishes a filter connection (step 203) to momentarily 

I buffer or discard subsequently transmitted multicast packets 
from the source host imtil network connections to receivers 
may be established. At step 204, the source switch then 
composes a sender present message indicating the presence 
of a new sending host to a new multicast group. 

; Alternatively, step 204 may be performed after the estab- 
lishment of connections for local host receivers in step 202. 
The soiuce switch then reliably announces the sender 
present message (step 205) to all other switches on the 
network by transmitting the sender present message onto 

, each of the switch' network ports. The announcement of the 
single sender present message in a reliable fashion avoids 
having to flood the network with multicast packets. 

FIG. 7B shows an alternative processing embodiment 
similar to that of FIG. 7A, but handling a case where a router 
45 is attached via a communications link to the local switch. 
The new source host sending to the new multicast group is 
detected (step 360) and then the local switch determines if 
there are local hosts or routers which are established or 
waiting as receivers for the multicast group packets (step 
50 361). If a router neighbors the switch, there may be hosts on 
the router network which may request to receive (i.e.ijoin) 
the new multicast group. IGMP may be used to set up a 
proxy multicast link between a router and neighboring 
switch. If the switch determines that a router or local host is 
55 requesting to receive the multicast packets from the new 
local source host, the switch's determines if a connection for 
this group akeady exists in the switch* connection table 
(step 363). If a connection does not exist, one is estabfished 
(step 36*^ which contains the multicast group address, the 
60 source host addresses, the input port from the source host, 
and the output port for the requesting local host or router. 

However, if a connection does exist for the multicast 
group (step 363) the switdi determines if there is a conflict 
with the existing connection (step 364). A conflict may occur 
65 if an already existing connection for the multicast group/ 
source pair does not list the proper input port for the 
group/source pair. This may occur if the source host has 
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moved to a different port on the local switch. If a conflict is next successive destination switch and therefore determines 

apparent, the existing connection is removed (step 366) from the map message output port to which the map message will 

the connection table and a new connection is estabUshed be sent (step 224). Then the switch makes siire that the map 

(step 367) containing the proper entries for the new group message output port is vaHd (step 227) and if it is not (i.e.: 

and source host addresses, and the output port of the local 5 the link is down or a failure exists for the map message 

host or router requesting to join the new group. After all of output port), an "Unmap Down Message" is sent back out 

these steps, a "sender present" message is composed (step the receive port to the switch which sent the map message. 

368 ) as in FIG. 7A and is then announced onto the switching Steps 227 and 228 ensure a connection may be established 

network (step 369). up towards the source switch, and if not, these steps notify 

The steps in FIG. 7B provide a more robust multicasting jq the downstream switch of a failure. In step 222, the switch 

scheme which allows source hosts to move and provides for checks its connection table to determine if a connection 

appropriate connection updating capability. This embodi- exists for the multicast group/source combination identified 

ment also provides for the ability to use IGMP to allow in the map message. If a connection already exists for this 

router networks to join into multicasting sessions originating group/source pair, the switch adds the recorded received port 

from a switch network. 15 parameter value to the output port list for the group/source 

FIG. 8 describes multicast switch operation in response to connection entry in the switch's connection table (step 223). 

receiving a "sender present" message (step 210). A switch However, in step 222, if the group/source combination does 

receiving this message (i.e., Mcast switches 15-19 in FIG. ^oi exist in the connection table, the switch then establishes 

5) continues announcing the "sender present" message (step a connection in a connection table (step 225) containing the 

2U) onto all network ports other than the network port 20 nJ^Hicast group address as the destination address, the map 

which the "sender present" message was received on. The message output port as the input port of the connection, the 

announcement protocol used ensures the reUable deUveiy of source host MAC address as the source destination, and the 

messages and prevents message looping and redundancy. receive port parameter value as the output port for the 

After announcement, the switch then checks for any local connection. Hiis connection established in the connection 

host or router receiver ports which may exist and which may 25 table will switch multicast packets towards the receiving 

be requesting to join the multicast group designated in the switch which was the originator of the map message. FinaUy, 

"sender present" message (step 212). If IGMP detects that ^ step 226, the switch delivers the map message to the next 

there are local host receivers or routers waiting to join any switch on (up) the path towards the source switch by sending 

groups designated in the sender present message, a loop is t^e map message onto the map message output port. In this 

entered (step 215) for each group/source pair designated in 30 fashion, the processing steps of FIG. 9 cause any switch 

the sender present message. The switch determines if a which receives a map message to create a connection in the 

connection already exists for the group/source pair for this connection table for a new receiving switch for that group, 

loop iteration (step 216) and if so a conflict check is or alternatively, to add a multicast packet path to an akeady 

determined for the existing connection (step 217) much the existing connection for that group so that the originating 

same way as described above with reject to FIG. 7B. The 35 switch of the map message may begin receivmg multicast 

conflict check in step 217 makes sure each part of the packets. 

existing connection is correct. If the existing connection has From the foregoing switch processing description, 

a conflict (i.e., its input port is not proper), the existing through the use of "sender present" messages and "map 

connection is deleted (step 218). After deleting the messages", the multicasting protocol implemented in the 

connection, or if a connection did not already exist for the 40 muUicast switches of the present invention provides frar the 

group/source pair in step 216, a connection is made (step "signal out, connect back*' methodology. There is no need to 

213A) and a "map message" is composed (step 213B) which flood the network with initial multicast packets to all 

contains the network path of all intermediate switches switches and then pmne back a tree to only the desired 

between the receiving switch (which is creating and sending receivers. 

the map message) and the source switch (from which the 45 FIG. 10 shows die processing steps a multicast switch 

multicast packets originate). The path information entered in performs which allow local hosts of that switdi to join 

the "map message" is obtained from a separate protocol multicast group sessions. When a switdi receives an IGMP 

which switches use to maintain path information. The map "join group" message from a local host on a receive port 

message with the path information also contains a designa- (step 230), the switch first checks if connections for that 

tion of the multicast source host and group pair for which it 50 group exist in its connection table (step 231). If cormections 

is creating connections. The map message containing the for that group exist, the switch adds the receive port which 

return path is then delivered (step 214) up the network path the IGMP "join group" message was received from to the 

towards the source switch. The next group/source pair in the connection table (step 232). However, if connections for that 

sender present massage is then processed (step 219) as group do not exist, the switch determines if the multicast 

described previously. Each map message, as will be shown, 55 group is new to the switch (step 234). The group may be 

wiU cause each intermediate switch along the return path to considered new for example, if the switch has not joined 

the source to establish an appropriate source/group connec- other local hosts to this group. If the group is not new, 

tion for multicast packets for this group so that they may be processing is complete at step 235. However, if the switch 

switched through the network to the receiving switch. does not have local hosts joined to the group, the switch 

FIG. 9 shows the processing a switch performs upon 60 announces a "switch join group" announcement message 

reception of a "map message". After reception of the "map onto the switching network 233. The switch join group 

message" (step 220), a switch first records the input port, message, as wiU be shown, reliably notifies other switches 

from which the map message was received, into a received that a switch is requesting to join the multicast group 

port parameter (step 221). The received port parameter will requested in the switch join group message, 

be used later to establish a connection for the forthcoming 65 FIG. 11 shows the processing steps performed by a switch 

muhicast packets. Next, the switch examines the return path upon reception of a "switch join group" announcement 

information contained in the map message to detennine the message (step 240). In this embodiment, the receiving 
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switch continues reliably aonounciag the switch join group 
message to other switches (step 244). Next, the receiving 
switch detemaines if a multicast router is attached to one of 
the ports of the switch (step 241) and if so, the switch uses 
IGMP to "proxy" join Oie requested multicast group speci- 
fied within the "switch join group" announcement message 
to the router attached to the switch (step 242). By using 
IGMP, the switch appears as a local host to its neighboring 
router. By proxy joining the requested multicast group, any 
packets received by the router will be forwarded to the 
switch network. Steps 241 and 242 then ensure that any 
multicast packets for the requested group which arrive at the 
switch network from a router will be properly switched to 
the appropriate receiving switches. Next, the multicast 
switch determines if there are any local host sources trans- 
mitting multicast packets to the group requested (step 243). 
If the switch determines that it has local sources transmitting 
packets to the requested group, the switch sends a directed 
"sender present" message (step 245) directly to the switch 
that sent the "switch join group" announcement message. 

The processing in FIG. 11 allows each switch in the 
network to notify the originator of the "switch join group" 
message if it has either local host senders to the requested 
group, or if it has an attached router which may also be 
providing multicast packets to the switch network for . the 
requested group. The IGMP proxy join alerts the router that 
the switch is both a sender and a receiver for multicast 
packets to the group. This allows any switch with an 
attached router to become a proxy switch for muhicast group 
packets between a switching network and a router network. 
In an alternative embodiment, steps 241 and 242 may be 
omitted for a case in which multicast switches in a switch 
network have no attached routers. 

The following FIGS. 12-17 describe the switch process- 
ing which allows the removal of multicast connections 
within the network and also allows for failure processing in 
the event that a host, switch or communications link goes 
down. 

FIG. 12 shows the processing steps a multicast switch 
performs when that switch's IGMP detects no local receiv- 
ing hosts for a multicast group on an output port connected 
to a local host Unk (step 250). As previously mentioned, 
IGMP running on a switch periodically polls all of that 
switch's local hosts for multicast group membership. If 
IGMP detects that no local hosts have responded to a 
specific multicast group poll message on a specific output 
port, for each connection in the connection table containing 
that group (step 257), the switch removes that output port 
from the connections for that particular multicast group in 
the connection table (step 251). The switch then determines 
if any more output ports exist for that multicast group 
connection (step 252). If there are other output ports still 
existing for the group connection in the connection table, 
processing is completed is step 253. However, if the mtil- 
ticast group connection in the connection table no longer 
contains any output ports, the switch determines if the input 
port for the connection for that multicast group is a host or 
network port (step 254). If the input port is cormected to a 
host link, the switch removes this connection for that mul- 
ticast group from the connection table (step 256). In step 
254, if the input port is a network port (i.e., connected to a 
network link), the switch composes and delivers an "unmap 
up" message on the input port listed for that cormection (step 
255). Then processing returns to step 257 for the next entry 
in the connection table listing the group detected in step 250. 

In this manner, switch processing removes multicast 
connections from a connection table which no longer con- 
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tain any output ports for the multicast packets and which 
designate host links as their input ports. However, if the 
input port is a network port, and no more output ports exist 
for a multicast group cormection in the connection table, the 

5 switch sends an immap up message onto the input port 
designated in the connection. This unmap up message will 
notify the switch at the receiving end that the local switch no 
longer needs to receive multicast packets for this particular 
group, as will be described. 

jQ FIG. 13 shows the steps a switch undertakes in response 
to receiving an "unmap up" message (step 260). The switch 
first records the receive port number on which the **unmap 
up" message was received(step 261). The receive port 
number is then removed from the output port of each 

^5 multicast group entry in the connection table for the switch 
(step 262). The switch then delivers an "unmap down" 
message on the receive port (step 263), which serves as an 
acknowledgment of the reception of the **unmap up" mes- 
sage. Next, the switch determines if there are any more 

20 output ports for the multicast group connection being 
unmapped (step 264). If other output ports exist for this 
group connection, the processing finishes (step 265). 
However, if there are no more output ports listed for the 
multicast group connection, the switch determines if the 

25 inptit port for the connection is a host link or network link 
port (step 266). If the input port listed for the connection is 
a network port, the switch delivers an "unmap up" message 
onto the input port listed in the groups connection (step 267). 
However, at step 266, if the input port is a host port, the 

3Q connection itself is removed from the connection table for 
the multicast group (step 268). 

The combined processing of steps 260-268 in FIG. 13 
cause a multicast switch to adjust or remove the appropriate 
multicast cormections based on the received unmap mes- 

35 sage. Furthermore, if the switch receiving such a message 
serves as an intermediate switch only (i.e., has no local hosts 
for the multicast group), step 267 insures that the unmap up 
message is further propagated to the next switch up the data 
stream of the multicast packets. The urmiap up message is 

40 thus used to successively remove multicast group connec- 
tions from connection tables in switches where there arc no 
local or network receivers to accept the packets. 

FIG. 14 shows the processing steps a switch performs 
upon reception of an "tmmap down" message; this serves as 

45 an acknowledgment to a previously sent "unmap up" mes- 
sage. After the "unmap down" message is received (step 
270), the unmap down message is deUvered on all output 
ports for the group/source connection pair in the switch's 
connection table (step 271). Step 271 ensures that any down 

50 stream switches in the multicast packet flow, which may be 
expecting multicast packets to be forwarded by the switch 
performing the processing of FIG. 14, should no longer 
expect delivery of these packets from the upstream switch. 
After propagation of the "unmap down" message to down 

55 stream switches or hosts on the output ports, the switch 
removes the group/source connection from the connection 
table (step 272). 

FIG. 15 shows the processing steps according to one 
embodiment which a switch performs upon detection of a 

60 fink or port failure. When such a failure is detected, the 
multicast switch determines the port niunber upon which the 
failure occurred (step 280). The switch then enters a loop to 
examine each cormection in its connection table (step 281) 
to determine if any of the connections are effected by the 

65 link or port failure. For each connection, the switch deter- 
mines if the port or link is an input port for the particular 
connection (step 282), and if it is, the switch delivers an 
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"unmap down** message to each network output port listed Group" message (Step 304). If there is a router attached to 

for that connection (step 283) in the connection table and this switch (step 305), the switch checks a database to 

deletes this connection (step 291). Steps 282 and 283 determine if there arc any more switches receiving packets 

provide notification to the downstream switches that the for this multicast group on the switch network (step 308). If 

present switch will no longer be able to provide muhicast 5 there are no more switches receiving this group, the switch 

packets since a link or port at which the packets arrive is no notifies the router via IGMP that the router no longer needs 

longer functional. If the failed link or port is not an input port to forward packets for this group to the switch network (step 

for the current connection being examined, the switch deter- 307). If there is no neighboring router (step 305) or there are 

mines if it is an output port for the connection (step 284), and other switches still receiving the group packet in the switch 

if not, proceeds to the next connection in the table (step 289). network (step 308), the switch does nothing (step 306). If 

However, if the current connection being examined docs hst this fashion, switch leave group messages may be used to 

the failed port as an output port (step 284), the switch track overall switch network group membership and can 

removes the output port firom the connection (step 291) and allow a switch attached to a router network (i.e.: a proxy 

then determines if there are other output ports which exist switch) to request or remove group membership from the 

for the connection, besides the failed port (step 285). If there router network. 

are other output ports, then the connection may be main- An example will now be described of these processing 

tained ai^ processing proceeds to the next connection (step steps in relation to FIGS. 5 and 6 and the flow chart of FIG. 

289). However, if the only output port listed for a connection 19. 

is the failed port, the switch determines if the connection's Iq FIG. 5, assume multicast host I begins transmitting 

input port is a host or network link input port (step 286). If multicast packets containing "QRS" video daU addressed to 

it is a network link, the switch dehvers an "immap up" 20 muhicast group Y (step 320). Multicast switch 14 receives 

message up the input port listed for the connection (step the new group Y packets over host hnk 10 on port 30 (step 

287). The '*unmap up" message notifies the up stream switch 321), as shown in the exploded view of switch 14 in FIG. 6. 

that this switch cannot forward any multicast packets fiirther Multicast switch 14 determines if there are any local host 

than itself due to a failed port. However, if the input port for receivers requesting to join group Y on other host links 

the connection containing a failed output port is a host port, 25 besides host link 10 (step 322). For example, multicast host 

the group/source connection is removed from the connection 2 may use IGMP to join group Y, and if so, multicast switch 

table for that group (step 288). Processing then proceeds to 14 will establish a local group/source connection for the 

successive conneaions in the connection table (step 289). group Y packets from host 1 in its connection table (step 323 

After all connections have been processed for the failed link jn piG. 19). After handling local connection step up, mul- 

or port, processing completes at step 290. 3^ ticast switch 14 then reliably announces multicast Group Y's 

From the foregoing description, when a link or port fails, presence via a "group Y sender present" message on all 

the switch uses unmap down and unmap up messages to network ports (step 324). Multicast switch 14 becomes a 

notify either down stream or up stream switches of the source switch for group Y packets. In FIG. 5, this message 

failure and adjusts its connection table accordingly. would be transmitted on network links 24 and 20 to multi- 

FIG. 16 describes the switch processing upon detecting 35 cast switches 19 and 15, respectively. As the "sender 

the loss of a local sending host (i.e., a source) to a multicast present" message from switch 14 propagates through the 

group (step 300). When a local host source stops sending switch network 28, each switch 15-19 performs the pro- 

muhicast packets to the group, its local switdi detects this cessing as previously described in FIG. 8. 

after a predetemained timeout period and delivers an "unmap Suppose for this example, that multicast host 3 has 

down" message to each output port Usted in the existing 40 signaled to its local multicast switch 16, via IGMP, that it 

connection for that group/souicc pair in the connection table wants to receive group Y multicast packets (i.e., to join 

(step 301). Then the switch removes the group/source con- group Y). Multicast switch 16 will eventually receive the 

nection pair from the connection table (step 302). propagated "sender present" message (step 325) and will 

Accordingly, v/hcn a local host source on a switch stops now be "aware" of the existence of the multicast group Y. 

sending to a multicast group, the local switch, after a period 45 Switch 16 then determines if there arc local host receivers 

of time, begins the propagation of the unmap down message requesting to join group Y (step 326). Since host 3 has made 

which removes all connections within the network for the such a request, switch 16 then determines, via a known 

group/source packets for that multicast group. Thus, any protocol which keeps track of the best network paths 

switch in the network which switches packets matched to the between switches, the best path througji the switch network 

tuple for that specific multicast group and that specific 50 back to the source switch (step 327). Once the best remm 

source host, will in turn remove the appropriate connections. path to the source switch has been determined, switch 16 

FIG. 17 shows the processing a switch undertakes when composes a map message containing this return path and a 

the switch detects there are no more local receivers for a designation of the multicast group Y and source host address 

multicast group (step 303). In this case, the switch which is being joined, and sends this map message out the 

announces via a "Switch Leave Group" message sent to all 55 network port of switch 16 towards the sending switch, along 

other switches (step 309) that this switch no longer needs to the predetermined best network path (step 328). As previ- 

receive packets for the particular multicast group. This ously described, as the map message travels along the 

message may be primarily used for the switches which predetermined path back to the source switch of the group Y 

handle proxy joining of groups to router networks. A switch multicast packets, a connection is established for the group/ 

with a neighboring router may keep track of which groups 60 source pair in the connection table of each intermediate 

are needed to be sent from the router network to the switch switch (step 329). When the map message reaches the 

network. Thus, when a switch no longer has subscribers to original source switch, and last connection is established in 

a group, it notifies the switching network and the proxy source switch 14' s connection table, the multicast packets 

switches keep track of switch group membership as will be will begin to be switched through the switching network to 

explained with respect to FIG. 18. 65 the receiving multicast host 3. 

FIG. 18 shows the processing a switch undertakes accord- FIG. 20 describes another embodiment of the invention in 

ing to one embodiment after receiving a "Switch Leave which a multicast host may join, via its local switch, to a 



12/17/20a3, EAST Version: 1.4.1 



us 6,331,983 Bl 

33 34 

multicast group session which is already being transmitted path, the map message containing the group address, 

within a switch network. For example, suppose the process- the source host address and the predetermined path 

ing steps previously described with respect to FIG, 19 have between the receiving switch and the source switch, 

been completed and there is now an existing multicast 2. The method of claim 1, wherein a switch receiving the 

session taking place between sending host 1 and receiving 5 map message determines if there is an entry in its connection 

host 3 along the network path through multicast switches 14, table for the group address and the source host address, and 

19 and 16. Further suppose that a multicast software appli- y^g^ ^^j^s an outport to the entry identifying the port on 

cation running on multicast host 6 for example, wants to join y^\iich the map message was received, 

the existing multicast group Ysession (step 340 in FIG. 20). 3 -j^^ ^^^^^ ^^^^ ^ wherein prior to sending the 

The multicast host application directs muUicast host 6 to 10 ^^^^^ ^^^^^^ message the source switch establishes an 

send an "IGMP Group Y join'' request to its local multicast ^ connection table for the group address and the 

switch 18, and then waits for the multicast packets (step j^^^ ^ with one of: 
341).Multicastswitchl8receivesthe"IGMPGroupYjoin" 

request on the port connected to host link 13 (step 342). W no ports; or 

Switch 18 first determines (as per processing in HG. 10) if 15 (b) an outport identifying any access ports to local hosts 

any group Y connections already exist in its connection table »hat wish to join the group address, 

(step 343 in FIG. 20). If such connections exist, the output 4. The method of claim 1, wherein a switch receiving the 

port for host 6 is added to the existing connection for the map message determines if there is an entry m its connecUoa 

group Y multicast packets (step 344 in the local connection table for the group address and the source host address, and 

table). If no connections exist for group Y, switch 18 20 ^ 00. adds an entry to its connection table for the group 

announces a "switch join group Y" message on aU of its address, the source host address, an inport identifying the 

network ports (step 345). This processing was previously Port directed toward the source switch according to the 

described with respect to FIGS. 10 and U. In FIG. 5, when predetermined path, and an outport identifying the port on 

the "switch join group Y" message has propagated back to which the map message was received, 

the source switch 14 (step 346), switch 14 then sends a 25 5. The method of claim 4, wherein if the reoeivmg switch 

directed "group Y sender present" message directly to is not the source switch, the receivmg switch sends the map 

switch 18 (step 347). This processing was described in FIG. message on the predetermined path toward the source 

11. Then, as previously discussed, when the sender present switch. 

message reaches switch 18, switch 18 performs the process- ^ The method of claim 4, wherein each switch receives 

ing according to the reception of a sender present message 30 the map message and only switches on the prcdetermmed 

as described in FIG, 8. Switch 18 sends a "map" message path implement the determines step, 

back up the network path towards source switch 14 which 7. The method of claim 3 wherein when the source switch 

estabUshes a connection for the multicast packets for group receives the map message it adds to its entry m the connec- 

Y at each intermediate switch (i.e., switches 14 and 15 for tion table for the group address and source host address an 

example). 35 oi^tport identifying the network port on which it received the 

Various embodiments of the present invention have thus ^ ^ 1 • 1 1. • u u *u 

^ , 8. The method of claim 2, wherein each switch on the 

been descnbed mcluding an apparatus and processmg steps . • , l * * 1 * u j 

which allow multicastkg to be implemented across a prcdetermmed path sv^tches multi^^^ 

switched network. These and other modifications of the !u , • o • *k . u w 

.„ . * * 1 -11 ^ • *u ^ 4n 9. The method of claim 8, wberem the packet switching 

mvention will be apparent to those skilled m the art and are ^ . . e ted in hardware 

intended to be within the scope of this invention. 1*?^™'^^^ *j r 1 • o u • »*• 1 u * 

„« ^ . I . J . ^ 10. The method of claim 8, wherem multiple source hosts 

What IS claimed is: j. t^- . 1 / ^ • • 

1. In a switchcd-based communications network includ- a|f ^nd^S multicast packets contaimng one or more group 

ing a plurality of hosts and switches connected by links, each ^^t^* - 0 u 

SN^tch having at least one network port connected to another ^5 U- The method of claim 8, wherem: 

switch and at least some switches having access ports a local switch determines whether a local host connected 

connected to hosts, each host having a unique address, and to o^e of its access ports wishes to join a designated 

each switch including a connection database of valid con- group address; 

nections between different ports on the switch and a switch- if so, the local switch checks its connection table for an 

ing semp mechanism for establishing temporary connections 50 entry identifying the designated group address; 

between the different ports on the switch, the improvement {f yes, the local switch adds the access port on which the 

comprising a method for processing multicast packets com- local host is connected as an outport for the connection 

prising steps of: table entry; 

receiving, at a source switch, a multicast packet on an \f not, the local switch composes and sends a join group 

access port from a source host; message to the other switches, the join group message 

determining, by the source switch, a group address firom containing the designated group address and the local 

the multicast packet; and switch address, 

composing and sending, by the source switch, a sender 12. The method of claim U, wherein the join group 

present message, containing the group address and the go tnessage is sent to all other switches, 

source host address, to other switches on its network 13. The method of claim 11, wherem: 

ports wherein a receiving switch receives the sender a switch receiving the join group message determines if a 

present message and determines whether a local host local host connected to any one of its access ports is the 

attached to one of its access ports wishes to join the source host for the designated group address identified 

group address identified in the sender present message; 55 in the join group message; 

if yes, the receiving switch composes and sends a map if yes, the switch sends a sender present message to the 

message toward the source switch on a predetermined local switch. 
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14. The method of claim 11, wherein: 

a switch receiving the join group message determines if a 
router is attached to any one of its access ports; 

if yes, the switch notifies the router that the switch wishes 
to join the designated group address identified in the 
join group message. 

15. In a switched communications network including a 
plurality of hosts and switches connected by finks, each 
switch having at least one network port connected to another 
switch and at least some switches having access ports 
connected to hosts, each host having a unique address, each 
switch including a connection database of vafid connections 
between different ports on the switch and a switching setup 
mechanism for establishing temporary connections between 
the diflPercnt ports on the switch, the improvement compris- 
ing a method of processing multicast packets comprising 
steps of: 

determining, at a local switch whether a local host con- 
nected to one of its access ports wishes to join a 
designated group address; 

if so, checking, at the local switch a connection table for 
an entry identifying the designated group address; 

if the entry exists, adding, by the local switch, the access 
port on which the local host is connected as an outport 
to the connection table entry; and 

if the entry does not exist, composing and sending, by the 
local switch, a join group message to the other switches 
along predetermined paths formed between switches, 
the join group message containing the designated group 
address and the local switch address. 

16. The method of claim 15, wherein if the local switch 
receives no response to the join group message, the local 
switch maintains for some time period the wish of the local 
host to join the designated group address. 

17. In a switched-based communications network includ- 
ing a plurality of hosts and switches connected by links, each 
switch having at least one network port connected to another 
switch and at least some switches having access ports 
connected to hosts, each host having a unique address, and 
each switch including a connection database of valid con- 
nections between different ports on the switch and a switch- 
ing setup mechanism for establishing temporary connections 
between the different ports on the switch, the improvement 
comprising a method for processing multicast packets com- 
prising steps of: 

determining, at a local switch, if the local switch has a 
local router attached to an access port and if so, adding, 
by the local switch, an identification of the port 
attached to the router to a database for forwarding 
and/or receipt of multicast group packets between a 
switching network and a routing network. 

18. The method of claim 17, wherein the database is 
periodically refreshed with an identification of multicast 
group addresses and source host addresses. 

19. The method of claim 17, wherein the local switch 
sends a router present message to other switches; 

each receiving switch responds with a group present 
message identifying the group addresses to which its 
attached hosts are joined; and 

the local switch notifies the router of its desire to receive 
multicast packets for all designated group addresses. 

20. In a switched-based communications network includ- 
ing a plurafity of hosts and switches connected by links, each 
switch having a source address and at least one network port 
connected to another switch and at least some switches 
having access ports connected to hosts, each host having a 
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unique address, and each switch including a connection 
database of valid connections between different ports on the 
switch and a switching setup mechanism for establishing 
temporary connections between the different ports on the 
5 switch, the improvement comprising a switch for processing 
multicast packets including: 

means for receiving a multicast packet on an access port 

from a source host; 
means for determining a group address from the muUicast 
packet; and 

means for composing and sending a sender present 
message, containing the group address, the source host 
address, and source switch address, to other switches 
j5 ' on its network ports, 

21. In a switched-based communications network includ- 
ing a plurafity of hosts and switches connected by links, each 
switch having at least one network port connected to another 
switch and at least some switches having access ports 

2p connected to hosts, each host having a unique address, and 
each switch including a connection database of valid con- 
nections between different ports on the switch and a switch- 
ing setup mechanism for establishing temporary coimections 
between the different ports on the switch, the improvement 
^ comprising a method for processing multicast packets com- 
prising steps of: 

receiving, at a source switch, a multicast packet on an 

access port from a source host; 
performing at least one of a group of actions including 
30 buffering and discarding of one or more multicast 
packets until a connection is estabUshed to a host 
designated as a receiver of the multicast packet, 
determining, by the source switch, a group address from 

the multicast packet; and 
composing and sending, by the source switch, a sender 
present message, containing the group address and the 
source host address, to other switches on its network 
ports. 

22. The method of claim 21, wherein: 

40 

a receiving switch receives the sender present message 
and determines whether a bcal host attached to one of 
its access ports wishes to join the group address iden- 
tified in the sender present message; 
45 if yes, the receiving switch composes and sends a map 
message toward the source switch on a predetermined 
path, the map message containing the group address, 
the soiu-ce host address and the predetermined path 
between the receiving switch and the source switch. 
5Q 23. The method of claim 22, further comprising program- 
ming the connection along the predetermined path between 
the source host and host designated as a receiver. 

24. The method of claims 22, wherein a switch receiving 
the map message determines if there is an entry in its 

55 connection table for the group address and the source host 
address, and if yes, adds an outport to the entry identifying 
the port on which the map message was received, 

25. The method of claim 21, wherein prior to sending the 
sender present message the source switch establishes an 

gQ entry in its connection table for the group address and the 
source host address and an outport with one of: 

(a) no ports; or 

(b) an outport identifying any access ports to local hosts 
that wish to join the group address. 

65 26. The method of claim 22, wherein a switch receiving 
the map message deteraaines if there is an entry in its 
connection table for the group address and the source host 
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address, and if no, adds an entry to its connection table for 
the group address, the source host address, an inport iden- 
tifying the port directed toward the source switch according 
to the predetermined path, and an outport identifying the 
port on which the map message was received. 

27. The method of claim 26, wherein if the receiving 
switch is not the source switch, the receiving switch sends 
the map message on the predetermined path toward the 
source switch. 

28. The method of claim 26, wherein each switch receives 
the map message and only switches on the predetermined 
path implement the determines step. 

29. The method of claim 25, wherein when the source 
switch receives the map message it adds to its entry in the 
connection table for the group address and source host 
address an outport identifying the network port on which it 
received the map message. 

30. The method of claim 24, wherein each switch on the 
predetermined path switches multicast packets based on its 
connection table entry. 

31. The method of claim 30, wherein the packet switching 
is implemented in hardware. 

32. The method of claim 30, wherein multiple source 
hosts are sending multicast packets containing one or more 
group addresses. 

33. The method of claim 30, wherein: 

a local switch determines whether a local host connected 
to one of its access ports wishes to join a designated 
group address; 
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if so, the local switch checks its connection table for an 
entry , identifying the designated group address; 

if yes, the local switch adds the access port on which the 
local host is connected as an outport for the connection 
table entry; 

if not, the local switch composes and sends a join group 
message to the other switches, the join group message 
containing the designated group address and the local 
switch address. 

34. The method of claim 33, wherein the join group 
message is sent to all other switches. 

35. The method of claim 33, wherein: 

a switch receiving the join group message determines if a 
local host connected to any one of its access ports is the 
source host for the designated group address identified 
in the join group message; 

if yes, the switch sends a sender present message to the 
local switch. 

36. The method of claim 33, wherein: 

a switch receiving the join group message determines if a 
router is attached to any one of its access ports; 

if so, the switch notifies the router that the switch wishes 
to join the designated group address identified in the 
join group message. 
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